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RECEIVING WIRELESS INFORMATION ON 
A MOBILE DEVICE WITH REDUCED 
POWER CONSUMPTION 

CROSS REFERENCE TO RELATED TO 
APPLICATIONS 

Reference is hereby made to U.S. Patent application, Ser. 
No. 09/107,724, filed Jun. 30, 1998, entitled "SYSTEM 
AND METHOD FOR RECEIVING WIRELESS INFOR- 
MATION ON A MOBILE DEVICE", now abandoned; and 
co-pending U.S. Pat. application Ser. No. 09/107,666, filed 
Jun. 30, 1998, entitled "SYSTEM FOR DELIVERING 
DATA CONTENT OVER ALOW BIT RATE TRANSMIS- 
SION CHANNEL", which have all been assigned to the 
same Assignee as the present invention and are hereby fully 
incorporated by reference. 

The present application is based on provisional applica- 
tion Serial No. 60/070,720 filed on Jan. 7, 1998, and on 
provisional application Serial No. 60/075,123 filed on Feb. 
13, 1998. 

BACKGROUND OF THE INVENTION 

The present invention relates to personal mobile comput- 
ing devices commonly known as handheld portable com- 
puters. More particularly, the present invention relates to a 
system and method for receiving wireless information on a 
mobile device. 

Mobile devices are small electronic computing devices 
often referred to as personal digital assistants. Many of such 
mobile devices are handheld devices, or palm-size devices, 
which comfortably fit within the hand. One commercially 
available mobile device is sold under the trade name Hand- 
Held PC (or H/PC) having software provided by Microsoft 
Corporation of Redmond, Wash. 

Generally, the mobile device includes a processor, ran- 
dom access memory (RAM), and an input device such as a 
keyboard and a display, wherein the keyboard can be inte- 
grated with the display, such as a touch sensitive display. A 
communication interface is optionally provided and is com- 
monly used to communicate with a desktop computer. A 
replaceable or rechargeable battery powers the mobile 
device. Optionally, the mobile device can receive power 
from an external power source that overrides or recharges 
the built-in battery, such as a suitable AC or DC adapter, or 
a powered docking cradle. 

In one common application, the mobile device is used in 
conjunction with the desktop computer. For example, the 
user of the mobile device may also have access to, and use, 
a desktop computer at work or at home. The user typically 
runs the same types of applications on both the desktop 
computer and on the mobile device. Thus, it is quite advan- 
tageous for the mobile device to be designed to be coupled 
to the desktop computer to exchange information with, and 
share information with, the mobile device. 

Another technique for providing information to the 
mobile device is described in the above-identified 
co-pending U.S. Patent applications. Generally, the method 
and system described therein allow the mobile device to 
receive information over a wireless, low bit-rate channel or 
transport, such as a pager network. For example, such 
information can include electronic mail or news, weather, 
sports, traffic and local event information typically obtained 
from a desktop computer connected to the Internet. 

However, the limited battery power available on the 
mobile device can present significant obstacles in transfer- 



59,464 Bl 

2 

ring information using the wireless low bit-rate channel. For 
example, the mobile device should be able to receive infor- 
mation over the wireless transport at any time. However, if 
the mobile device was merely left on, awaiting information 

S to be received, the battery for the mobile device would be 
quickly depleted. This method of operation would require 
the user to constantly recharge or replace the battery. 

Alternatively, a wireless receiver on the mobile device can 
turn on the mobile device when it detects that information is 

10 being sent to the mobile device. However, if large amounts 
of information are being transmitted over the wireless 
transport, the wireless receiver can turn on the mobile device 
so often that again the battery for the mobile device can be 
quickly depleted. 

15 Another drawback of most wireless receivers for a mobile 
device is that the wireless receiver requires its own battery, 
separate from the battery used on the mobile device since the 
mobile device can be turned off at any time. This increases 
the size, weight and cost of the wireless receiver as well as 

20 complicates use for the user since he must maintain both 
batteries. 

There is a continuing need to improve wireless commu- 
nication with a mobile device. In particular, there is a need 
to efficiently process information transmitted over a wireless 
25 channel to the mobile device in order to conserve battery 
resources on the mobile device. 

SUMMARY OF THE INVENTION 

30 A system and method for receiving wireless information 
on a portable computing device includes powering a wire- 
less receiver only from a battery of the portable computing 
device. Receiving wireless information and storing the wire- 
less information in memory of the wireless receiver. The 

35 wireless receiver wakes up a processor of the portable 
computing device when the wireless information fills a 
threshold of the memory available in the wireless receiver. 
The wireless information is then transferred from the 
memory of the wireless receiver to the memory of the 

40 portable computing device. 

Another aspect of the present invention is a wireless 
receiver for use in a portable computing device. The wireless 
receiver includes a radio receiver for receiving wireless 
information, memory for storing the wireless information 

45 and a processor for analyzing the wireless information. The 
radio receiver, the memory and the processor are powered 
only from the portable computing device. 

Another aspect of the present invention includes a method 
for receiving wireless information on a portable computing 

so device, wherein the wireless information is transmitted to 
the portable computing device with respect to wireless 
addresses. The method includes providing a list of wireless 
addresses on the portable computing device. Each wireless 
address corresponds to selected information to be received. 

55 Each wireless address also includes an associated status 
entry indicating enablement of the wireless address. The 
method further includes selectively enabling and disabling 
the status entry for the wireless address to allow receipt of 
the corresponding information as a function of an operating 

60 parameter of the device. In one exemplary embodiment, the 
operating parameter indicates when the portable computing 
device is being powered or connected to an external source 
such as a power docking cradle. 

Further features of the present invention include a system 

65 and method for receiving wireless information on a portable 
computing device that includes receiving an information 
packet having a first portion with topic information indica- 
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tive of content, and a second portion having the content of source of information in real time. However, it should be 

the information packet. The first portion of the information understood that the present invention can be implemented in 

packet is compared to content filtered data stored on a a real time environment wherein the wireless transport 14 

portable computing device. At least the second portion of the provides two-way communication, 

information packet is forwarded to another component of the 5 The wireless transport 14 is used to send information to 

portable computing device if the first portion matches any of ^ mobile device 10 for storage in the object store 18 and 

the content filtered data. f° r usc by mc application programs 16. The wireless trans- 
port 14 receives the information to be sent from an infor- 

BRIEF DESCRIPTION OF THE DRAWINGS mation source provider 13, which, for example, can be a 

10 source of news, weather, sports, traffic or local event infor- 

FIG. 1 is a simplified block diagram illustrating one mation. Likewise, the information source provider 13 can 
embodiment of a mobile device in accordance with the receive e-mail and/or scheduling information from the desk- 
present invention. top computer 12 to be transmitted to the mobile device 10 

FIG. 2 is a more detailed block diagram of one embodi- through the wireless transport 14. The information from the 

ment of the mobile device shown in FIG. 1. 5 desktop computer 12 can be supplied to the information 

FIG. 3 is a simplified pictorial illustration of one embodi- source P rovider 13 throu S h suilable communication 

ment of the mobile device in accordance with the present hl *> * uch as a * lT * ci modem connection. In another 

invention embodiment, the desktop computer 12 and the information 

. , . ■ , ■« • r i source provider 13 can be connected together forming a 

FIG. 4 is a simplified pictorial illustration of another ^ ^ ntM (jLMJ) Qr a wide afea QtM ^ m 

embodiment of the mobile device in accordance with the 20 ^ Qetworking environments are commonplace in offices, 

present invention. enterprise- wide computer network Intranets and the Internet. 

FIG. 5 is a simplified schematic illustration of a wireless jf desired, the desktop computer 12 can also be directly 

receiver in accordance with the present invention. connected to the wireless transport 14. 

FIG. 6 is a flow chart illustrating a method of operation for ^ The object store 18 is preferably configured to store a 

the wireless receiver and the mobile device. plurality of individual records or objects, each comprising a 

FIG. 7 illustrates a detailed flow chart illustrating opera- plurality of fields or properties related to features of PIM 

tion of the wireless receiver and the mobile device. 16A, or to data viewable on the content viewer 16B. For 

FIG. 8 is a pictorial representation of a list of wireless example, where PIM 16A is an e-mail and scheduling 

addresses 30 P r °g ram > object store 18 is configured to store objects, each 

FIG. 9 illustra.es a general structure of a message packet °f ^ has a ?, lura f * ° f . P r °P erti ? " hich can * e assod " 

. • ,i l i j j -fL ated with e-mail, scheduling or calendaring features pro- 
transmitted to the mobile device in accordance with one , , nnxi A & & v 

. c 4U . . vided by PIM 16A. 

aspect of the present invention. , . ; . . „. 

m „ „ „ , -r- It is also worth noting that, m one embodiment, the mobile 

u?- , 10 15 I b £* dia f am / lustratm S raodules of a 35 device 10 can be coupled to the desktop computer 12 using 

mobile device for filtering based on content. My md commercially available, communication 

FIG. 11 is a flow chart illustrating a method of obtaining ^ ^ a suitable communications protocol. For 

and creating content filter data. instance, in one embodiment, the mobile device 10 commu- 

FIG. 12 is a flow chart illustrating a method of filtering a nicates with the desktop computer 12 with a physical cable 

message using content filter data. 4Q which communicates using a serial communications proto- 
col. Other communication mechanisms include infra-red 

DETAILED DESCRIPTION OF THE n R \ communication and direct modem communication. 

PREFERRED EMBODIMENTS [t fc ^ WQrth noling ^ ^ mobile device 10 m 0fle 

FIG. 1 is a block diagram of an exemplary portable embodiment, can be synchronized with the desktop com- 

computing device, herein a mobile device 10 in accordance 45 puter 12. In that instance, properties of objects stored in 

with the present invention. FIG. 1 illustrates that, in one object store 18 are similar to properties of other instances of 

preferred embodiment, the mobile device 10 is suitable for the same objects stored in the object store 18 on the desktop 

connection with, and to receive information from, a desktop computer 12 or on the mobile device 10. Thus, for example, 

computer 12, a wireless transport 14, or both. The wireless when one instance of an object stored in the object store 18 

transport 14 can be a paging network, cellular digital packet 50 on the desktop computer 12, the second instance of that 

data (CD PD), FM-sideb and, or other suitable wireless com- object in the object store 18 of the mobile device 10 is 

munications. However, it should also be noted that the updated the next time the mobile device 10 is connected to 

mobile device 10 may not be equipped to be connected to the the desktop computer 12 so that both instances of the same 

desktop computer 12, and the present invention applies object contain up-to-date data. This is commonly referred to 

regardless of whether the mobile device 10 is provided with 55 as synchronization. 

this capability. In order to accomplish synchronization, synchronization 
In any case, the mobile device 10 preferably includes one components run on both the mobile device 10 and the 
or more application programs 16 and an object store 18. The desktop computer 12. The synchronization components 
application programs 16 can be, for example, a personal communicate with one another through well defined inter- 
information manager (PIM) 16A that stores objects related 60 faces to manage communication and synchronization, 
to a user's electronic mail (e-mail) and scheduling or cal- FIG. 2 is a more detailed block diagram of the mobile 
endaring information. The application programs 16 can also device 10. The mobile device 10 includes a processor 20, 
include a content viewer 16B that is used to view informa- memory 22, input/output (I/O) components 24, a desktop 
tion obtained from a wide-area network (WAN), such as the computer communication interface 26 and a wireless 
Internet. In one embodiment, the content viewer 16B is an 65 receiver 27. In a preferred embodiment, these components of 
"offline" viewer in that information is stored primarily the mobile device 10 are coupled for communication with 
before viewing, wherein the user does not interact with the one another over a suitable bus 28. 
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Memory 22 is preferably implemented as non-volatile stylus 36. The stylus 36 is used to press or contact the 

electronic memory such as random access memory (RAM) display 34 at designated coordinates to accomplish certain 

with a battery back-up module (not shown) such that infor- user input functions. The miniaturized keyboard 32 is pref- 

mation stored in memory 22 is not lost when the general erably implemented as a miniaturized alpha-numeric 

power to the mobile device 10 is shut down. A portion of 5 keyboard, with any suitable and desired function keys which 

memory 22 is preferably allocated as addressable memory are also provided for accomplishing certain user input 

for program execution, while the remaining portion of functions. 

memory 22 is preferably used for storage, such as to FIG. 4 is another simplified pictorial illustration of the 

simulate storage on a disk drive. mobile device 10 in accordance with another preferred 

Memory 22 includes an operating system 30, the appli- io embodiment of the present invention. The mobile device 10, 

cation programs 16 (such as PLM1 6A discussed with respect as illustrated in FIG. 4, includes some items which are 

to FIG. 1), as well as the object store 18. During operation, similar to those described with respect to FIG. 3, and are 

the operating system 30 is preferably loaded into, and similarly numbered. For instance, the mobile device 10 as 

executed by, the processor from memory 22. The operating shown in FIG. 4, also includes the touch sensitive display 34 

system 30, in one preferred embodiment, is a "WINDOWS 15 which can be used, in conjunction with the stylus 36, to 

CE" brand operating system commercially available from accomplish certain user input functions. It should be noted 

Microsoft Corporation. The operating system 30 is prefer- that the display 34 for the mobile devices shown in FIGS. 3 

ably designed for mobile devices, and implements features and 4 can be the same size, or of sizes, but will typically be 

which can be utilized by PIM 16 A and content viewer 16B much smaller than a conventional display used with a 

through a set of exposed application programming interfaces 20 desktop computer. For example, the display 34 shown in 

and methods. The objects in object store 18 are preferably FIGS. 3 and 4 may be defined by a matrix of only 240x320 

maintained by PIM 16A, content viewer 16B and the oper- coordinates, or 160x160 coordinates, or any other suitable 

a ting system 30, at least partially in response to calls to the size. 

exposed application programming interfaces and methods. xh e m0D ile device 10 shown in FIG. 4 also includes a 

The I/O components 24, in one preferred embodiment, are 25 number of user input keys or buttons (such as scroll buttons 

provided to facilitate input and output operations from the 38) which allows the user to scroll through menu options or 

user of the mobile device 10. The I/O components 24 are other display options which are displayed on display 34, 

described in greater detail with respect to FIGS. 3 and 4. without contacting the display 34. In addition, the mobile 

The desktop computer communication interface 26 is device 10 shown in FIG. 4 also preferably includes a power 

optionally provided as any suitable, and commercially 30 button 40 which can be used to turn on and off the general 

available, communication interface. The interface 26 is used power to the mobile device 10. 

to communicate with the desktop computer 12, as described ft should also be noted that in the embodiment illustrated 

with respect to FIG. 1. in FIG. 4, the mobile device 10 includes a handwriting area 

The wireless receiver 27 receives information from the 35 42. Handwriting area 42 can be used in conjunction with the 

information source provider 13 and includes an antenna 31. stylus 36 such that the user can write messages which are 

The wireless receiver 27 is coupled to the bus 28 for stored in memory 22 for later use by the mobile device 10. 

communication with the processor 20 and the object store 18 In one preferred embodiment, the handwritten messages are 

to store information received from the wireless transport 14 simply stored in handwritten form and can be recalled by the 

in a manner described below. 4Q user and displayed on the display 34 such that the user can 

A power supply 35 includes a battery 37 for powering the review the handwritten messages entered into the mobile 

mobile device 10. The power supply 35 communicates with device 10. In another preferred embodiment, the mobile 

the processor 20 to control power provided to the above- device 10 is provided with a character recognition module 

described components. One aspect of the present invention such that the user can enter alpha-numeric information into 

is that the power supply 35 provides all power for the mobile 45 the mobile device 10 by writing that alpha-numeric infor- 

device 10, including the wireless receiver 27 without the mation on the area 42 with the stylus 36. In that instance, the 

need for an external battery as typically found in the prior character recognition module in the mobile device 10 rec- 

art. In a second aspect of the present invention, components ognizes the alpha-numeric characters and converts the char- 

of the mobile device 10, such as the I/O components 24, are acters into computer recognizable alpha-numeric characters 

provided power only when necessary to process the incom- 50 which can be used by the application programs 16 in the 

ing information. This aspect of the present invention is mobile device 10. 

discussed below in greater detail. Although illustrated in FIGS. 3 and 4 as a handheld 
Optionally, the mobile device 10 can receive power from portable computer, it should be understood that the present 
an external power source 41 that overrides or recharges the invention can be used in other forms of portable computing 
built-in battery 37. For instance, the external power source 55 devices such as pagers, laptops, computers designed for use 
41 can include a suitable AC or DC adapter, or a power in automobiles, and portable phones having computers, 
docking cradle for the mobile device 10. FIG. 5 is a simplified diagram of the wireless receiver 27 
FIG. 3 is a simplified pictorial illustration of one preferred as coupled to other components of the mobile device 10. 
embodiment of the mobile device 10 which can be used in Generally, information sent by the wireless transport 14 is 
accordance with the present invention. The mobile device 60 detected by a RF receiver 60 through the antenna 31. The RF 
10, as illustrated in FIG. 3, can be a desktop assistant sold receiver 60 provides the wireless information to a processor 
under the designation H/PC having software provided by the 62. The processor 62 temporarily stores the information in 
Microsoft Corporation. In one preferred embodiment, the suitable memory, forming, for example, a FIFO (first-in- 
mobile device 10 includes a miniaturized keyboard 32, a first-out) buffer. The processor 62 and memory 64 are 
display 34 and a stylus 36. In the embodiment shown in FIG. 65 operably coupled to an interface controller 66, which is 
3, the display 34 is a liquid crystal display (LCD) which uses commonly used to connect components to a computer 
a contact sensitive display screen in conjunction with the system. In particular, the interface controller 66 couples the 
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wireless receiver 27 to the bus 28 and to an interrupt does not pertain to the mobile device 10, such as when a 

controller 68 that is operably coupled to the processor 20 of wireless address (capcode) does not pertain to the mobile 

the mobile device 10. The interface controller 66 is designed device 10, and thus, the information can be discarded, 

and operates according to known industry standards such as Alternatively, the processor 62 can determine that all of the 

PCMCIA and Compact Flash Specifications. In one $ information can be temporarily stored in memory 64 for 

embodiment, the components of the wireless receiver 27 later retrieval by the processor 20 of the mobile device 10. 

form a removable card that can be selectively coupled to an After processing the information at step 88, operational flow 

expansion slot provided in the mobile device 10 wherein returns to step 82 where the wireless receiver 27 awaits 

suitable connectors are provided to couple the interface further transmitted information. 

controller 66 to the bus 28 and the interrupt controller 68 as 3Q Steps 86 and 88 illustrate how the wireless receiver 27 can 

well as connect the wireless receiver 27 to the power supply receive and process information without further interaction 

35 illustrated in FIG. 1. In the embodiment illustrated, the with other components of the mobile device 10. Thus, power 

interrupt controller 68 is shown as being separate from the consumption from the power supply 35 is conserved since 

processor 20. In other embodiments, the interrupt controller none of the other components of the mobile device 10 have 

68 can be designed as part of the processor 20. The com- s been turned on or operated at a higher power consumption 

ponents of the wireless receiver 27 can be manufactured rate. 

using known fabrication techniques as implemented in [f a t step 86, the wireless receiver 27 determines that the 
pagers, GSM phones, cellular phones or the like. Although information received must be further processed by the 
illustrated and discussed below with respect to the processor mobile device 10, operational flow continues to step 90. At 
62, it should be understood that discrete components can 2Q step 90, the processor 20 is awoken by the interrupt con- 
also be used in place of the processor 62. troller 68 as initiated by the processor 62. The processor 20 
Operation of the wireless receiver 27 and the mobile retrieves the information stored in memory 64 and processes 
device 10 is directed to efficiently use power from the power it to determine if user interaction is required. If user inter- 
supply 35 in order to maximize the operational time between action is required, operational flow proceeds to step 92 
recharging or replacement of the battery 37. In one preferred 25 whereat user input devices such as the keyboard 32 are 
embodiment, the wireless receiver 27 is powered and activated and the user is notified of the information through 
capable of receiving information from the wireless transport the display 34. 

14 at all times irrespective of whether other components of [f at step 90, the processor 20 determines that user 

the mobile device 10 are operational and receiving power. interaction is not necessary to process the information, the 

This allows the wireless transport 14 to send information to 30 processor 20 processes the information, turning on only 

the mobile device 10 even if the user is not interacting with those components of the mobile device 10 that are necessary 

the I/O components 24 of the mobile device 10. at step 94. For instance, the information received by the 

When it is desired that the mobile device 10 receive wireless receiver 27 could have exceeded the memory 

information at all times, power from the power supply 35 is capabilities of memory 64 and that the only required action 

principally provided to the interrupt controller 68 and the 35 is to store the information in the object store 18 or other 

wireless receiver 27, while all other components of the temporary memory provided in the mobile device 10. In 

mobile device 10 do not receive power, or receive only such a case, it is not necessary to activate or turn on the 

enough power to operate in a "suspend" mode or state. For keyboard 32 or the display 34. The processor 20 merely 

instance, the processor 20 can have three different modes of performs the required actions such as storing the information 

operation designed to maximize battery life by minimizing 4 q in memory in the mobile device 10 and returns to the 

power consumption: full speed, standby and suspend. Full suspend mode. Operational flow then returns to step 82 

speed mode is used to execute applications. Standby mode whereat the wireless receiver awaits further transmitted 

is used during brief idle periods. Standby mode can use less information. 

than one-tenth (Vioth) of full speed power. Suspend mode is Steps 90 and 94 thus illustrate how power consumption is 

used during long idle periods. Suspend mode can use less 45 conserved since only a partial wake-up of the mobile device 

than one -one thousandth (Vioooth) of full speed power. 10 has been performed to process the information. In other 

FIG. 6 illustrates a method of operation 80 of the mobile words, since only those components necessary to process the 

device 10 and the wireless receiver 27 to process informa- information have been turned on, while other components 

tion from the wireless receiver 27. At step 82, the wireless such as the display 34 remain off, power has been conserved 

receiver 27 and the mobile device 10 await information to be 50 and battery life has been extended. 

sent from the wireless transport 14. It is assumed that only At this point, it should also be noted that power can also 
the wireless receiver 27 and the interrupt controller 68 are be conserved by monitoring the source of system wake-ups 
receiving power and operating, while all other components and powering down the system as a function of the source, 
are either off or are in a suspend state, as discussed above. In particular, if the system is started in order to process an 
At step 84, information is received by the RF receiver 60 55 incoming message from the radio receiver 27, the system 
from the wireless transport 14. The information is then can be immediately shutdown upon the completion of pro- 
processed by the wireless receiver 27 at step 86. In the cessing. In contrast, when the system is started by the user 
embodiment illustrated, the processor 62 initially analyzes using the power button 40, or when the system starts to 
the information received and determines if the information provide the user a scheduled notification, such as an upcom- 
requires further processing by the processor 20 of the mobile 60 ing appointment, commonly the system will shutdown when 
device 10 and/or storage of the information in the object a period of non-use has occurred. Rather than waiting for the 
store 18. If at step 86, the processor 62 determines that the non-use period to lapse for processing an incoming message, 
processing or storage components of the mobile device 10 the system will shutdown immediately. However, if the 
are not needed, operational flow continues to step 88 system comes up because of the radio receiver 27 and then 
whereat the wireless receiver 27 processes or discards the 65 the user turns on the system, the system is allowed to remain 
information received. For instance, upon processing, the up and shutdown if the non-use period lapses. The source of 
processor 62 can determine that the information received system start can be monitored by the interrupt controller 68. 



05/24/2004, EAST version: 1.4.1 



US 6,21 

9 

FIG. 7 illustrates a detailed method of operation of the 
wireless receiver 27 and the mobile device 10. Generally, the 
wireless receiver 27 and the mobile device 10 process three 
types of incoming messages. A first type of message is not 
related to the mobile device 10 and is discarded. A second 
type of message is for the mobile device 10, but either can 
be received now for further processing at a later time, or can 
be received and processed at a later time. A third type of 
message is a high priority message that must be processed 
immediately and may require user interaction. All of these 
messages are efficiently handled by the method of FIG. 7 to 
conserve power and maximize battery life. 

In FIG. 7, wireless data 102 is received by the wireless 
receiver 27 as indicated at step 104. At step 106, the wireless 
information is examined by the processor 62 to ascertain if 
the wireless address of the information pertains to the 
mobile device 10. Typically, the wireless receiver 27 will be 
configured to respond to multiple wireless addresses, 
wherein each wireless address is used by one or a number of 
services to send information to the mobile device 10. For 
instance, one wireless address can be used to send high 
priority or personal messages to the mobile device 10, while 
other wireless addresses are used by one or more services to 
send other information to the mobile device 10. At step 106, 
the processor 62 ascertains if the wireless information 
pertains to a valid wireless address of the mobile device 10. 
If the wireless information does not pertain to the mobile 
device 10, it is discarded at step 108. 

At step 110, valid information for the mobile device 10 is 
stored in memory 64 of the wireless receiver 27. At this step, 
the processor 62 ascertains whether all of the information 
can be stored in memory 64, or if the mobile device 10 must 
be at least partially woke up. If the entire incoming infor- 
mation can be stored in memory 64, and the information is 
not high priority, the processor 62 stores the incoming 
information at step 112. If, on the other hand, the processor 
62 determines that the incoming information cannot be 
completely stored in memory 64, or that the incoming 
information pertains to a high priority message, for example, 
based on its wireless address, an interrupt request is gener- 
ated at step 114 to wake up the processor 20 of the mobile 
device 10. 

At this point, it should be noted that the size of memory 
64 is proportional to the rate at which wireless information 
is received by the wireless receiver 27 and the amount of 
time necessary for the processor 20 of the mobile device 10 
to wake up and begin extracting information from memory 
64. In one embodiment, the minimum amount of memory is 
provided in the wireless receiver 27 to store information 
until the processor 20 wakes up. In this manner, the size of 
memory 64 present in the wireless receiver 27 is less, 
thereby reducing the overall size of the wireless receiver 27 
and reducing its cost. 

At step 116, the processor 20 of the mobile device 10 
executes an initial body of code herein called the hardware 
abstraction layer (HAL). As part of the HAL wake-up code, 
HAL can call a function herein identified as 
CheckAndProcessRadioWakeup( ). Generally, this function 
checks if the radio receiver 27 needs some service and 
whether this service can be handled within HAL or if more 
components of the device will need to be started. The return 
values include: (1) a first value indicating that the radio 
receiver 27 has been serviced and there is no need to start 
other components (herein the first value is "HRADIO_ 
NOCONTINUE"); (2) a second value indicating that the 
display 34 should be turned on (herein the second value is 
'TOADIO.CONTINUE^DEO^N"); and (3) a third 



!9,464 Bl 

10 

value indicating that the display 34 should not be turned on 
(herein the third value is "HRADIO_CONTINUE_ 
VIDEO_OFF"). It should be noted that the return values 
can be ignored if other wake-up events occur. For instance, 

5 if the user presses the power button 40 about the same time 
as a radio interrupt is also received, and if the return value 
is "HRADIO_NO CONTINUE" or "HRADIO_ 
CONTINUE_VIDEO_OFF" the return value is ignored. In 
one embodiment, the radio receiver 27 registers information 

10 in a data block accessible by the HAL program indicative of 
the return values. The function is further described in detail 
below along with other functions and related information. 

Based on the return values, the processor 20 retrieves the 
information stored in memory 64 and examines it to deter- 

15 mine if the processor can store the information temporarily 
in a temporary buffer herein called the HAL buffer 120. If 
temporary storage in the HAL buffer 120 is possible, pro- 
gram flow continues to step 118 whereat the processor 20 
executes a device driver buffering routine which stores the 

20 information in the HAL buffer 120. The processor 20 then 
returns to the suspend state as indicated at step 122. 

If, on the other hand, at step 116, the processor 20 
determines that the information cannot be stored in the HAL 
buffer 120, for instance, where the information is high 

25 priority or of length exceeding the storage available in the 
HAL buffer 120, the processor 20 continues its wake-up 
process and a kernel is loaded at step 124. Each of the device 
drivers, such as a display driver, a serial port driver, etc., is 
then loaded at step 126. One particular driver that is loaded 

30 is a pager driver, which executes a filtering library function 
is indicated at step 128. The pager driver examines the 
information at step 130 to determine if the information is 
relevant to the mobile device 10. In contrast to step 106 
where information is discarded if it does not correspond to 

35 a wireless address recognized by the mobile device 10, 
information is discarded at step 130 if, based on its content, 
it is not relevant to the mobile device 10. For instance, the 
user may want to receive only football scores and no other 
sports scores. However, all of the sports scores may be 

40 transmitted with respect to a particular wireless address, thus 
information on baseball scores would not be discarded at 
step 106 since this information was transmitted with respect 
to the correct wireless address for football scores. However, 
at step 130, the content of the information is examined so 

45 baseball scores would be discarded, while football scores are 
retained. Steps 116 to 128 are very efficient and quick. In 
particular, the filtering step 128 examines the initial few 
bytes of the information and can quickly determine if the 
information should be kept or discarded. The number and 

so location of the bytes to examine are predetermined and 
agreed upon between the wireless information carrier and 
software developers. By examining only the first few bytes, 
the filtering step 128 can execute quickly (the processor 20 
is up for less time) and does not require all of the operating 

55 system services to be started. Non-relevant information is 
discarded at step 132. It should be noted that upon loading 
of the pager driver at step 128, any information stored in the 
HAL buffer 120 at step 120 from prior messages is retrieved 
and processed. 

60 It should be noted that in a further embodiment, the 
filtering step 128 can include other filtering parameters can 
be set by applications executable on the mobile device 10. 
In other words, besides filtering on designated bytes within 
the message, as discussed above, the filtering library func- 

65 lion can include other filtering parameters determined by 
application programs. For instance, a news viewer applica- 
tion can set a filter parameter where the mobile device 10 
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always rejects and does not store digital pictures and accepts associated operational status entry 163 indicating whether 

only the accompanying text. The filter parameters can be the wireless address is enabled or disabled. In a preferred 

passed from the application to the filtering library at filtering embodiment, the list of wireless addresses is static in that the 

step 128 using, for example, application program interfaces wireless addresses can not be changed by the user. However, 

(APIs). Filtering based on content is described below. 5 whether the wireless address is enabled or disabled is under 

If the information is relevant to the mobile device 10 and me control of the user and/or programming provided in the 

should not be discarded, program flow continues to step 134 mobile device 10 Referring back to FIG. 5, the processor 20 

to determine if user interaction is needed. For instance, if the °f ^ c mobile device 10 can selectively enable or disable 

message pertains to a high priority message requiring each wireless address in the list 150 in memory 64 via the 

acknowledgement by the user, the mobile device 10 com- 10 bus 28 and the interface controller 66. 

pletely wakes up with activation of the display 34 to indicate Selective enabling and disabling of wireless addresses 

that a message of high priority has been received. A full allows the mobile device 10 to further extend battery life by 

wake-up is indicated at step 136. not receiving information that is not of high priority. For 

In one embodiment, high priority messages are ascer- instance, the user may subscribe to an information service 

tained as a function of wireless addresses. FIG. 8 is a 15 provides general sports information that is transmitted 

pictorial representation of a list of wireless addresses 150. with respect to a certain wireless address. This information 

Associated with the radio addresses is information as to ma y be repeatedly transmitted over a given time period such 

which addresses are "high priority". In the embodiment as a number of hours. If the wireless receiver 27 were to 

illustrated, priority status entries 151 are provided and can continually process the information each time it is 

be set when an address is for high priority. Any information 20 transmitted, possibly waking up the mobile device 10 to 

or message that arrives on an address whose priority status process the information, the battery 37 (FIG. 1) can be 

entry 151 has been set will cause a full wake-up of the quickly depleted. By selectively enabling or disabling the 

mobile device 10. wireless address in the list 150 pertaining to this 

T r . fn . ■ llc .„ r • . „ m information, the wireless receiver 27 can quickly discard the 

If the information does not require user interaction, pro- . ' ^ • j / * ±. 

a * 4 no \* * no -fuff..,!™ 25 information at step 106 (FIG. 7) in order to conserve battery 

gram flow continues to step 138. At step 138, if buffer space . r 4 , v J ~ A c l-i j ■ 

exists and no farther processing is necessary, the processor P° wer - For ™ ta ° ce > ^ P roces *° r 20 of ^ mobl e devi « 

20 executes a buffer data routine at step 140 to store the 10 f <*» enaMe he ^ eles ? ad ^ ess . t0 T„ 

• c „• 4 * <iA<* tu in <u«™»„™. n «i, 0 information in list 150 when the mobile device 10 is 

information at step 142. The processor 20 then returns to the . . e , m . _ 

suspend state at step 122. If buffer space does not exist at M receivir^ power from toe external power source 41 (FIG 1). 

step 138, the mobile device 10 is powered-up without the 30 If the mobl ^ devK f. 19 * °P erat . m S ™derb att ery power, the 

j . * Z. . . \aa t*l * f ■ *u j processor 20 can disable the wireless address pertaining to 

display 34 at step 144. The information is then processed or \ ... *_ i-* 

1 u tc • u, ■ j , , a< ic the sports information in order to extend battery life, 

additional buffer space is ob tamed at step 46. If necessary, r 7 

access and storage can be made in the object store 18. The FIG - 9 illustrates one embodiment of an information 

processor 20 then returns to the suspend state at step 122. It P a <*et 160 of web content data received by wireless receiver 

should be noted that considerable power has been conserved 27. Wireless receiver 7 can receive messages of substantially 

since the user input/output (I/O) devices (display 34 and ™Y format. Many different types of header formats can be 

keyboard 32) have not been powered. However, if the user defined for receipt by the wireless receiver 27. FIG. 9 gives 

were to activate the mobile device 10 to turn it on, the but one illustrative type of packet formula, 

display 34 would immediately enable. 4Q Information packet 160 preferably includes a plurality of 

The mobile device 10 processes incoming wireless mes- portions, such as radio transport header 162, group address 

sages according to the above-described method in the back- bytes 164, topic filtering bytes 166, routing header 168 and 

ground whether or not the user is actively interacting with data 170 The radio transport header 162 includes wireless 

the mobile device 10 using the I/O components 24. It should address (capcode) information. As discussed above, the 

be noted that if the user were to turn off the mobile device 45 wireless address information is an identifier used to send a 

10, the wireless receiver 27 wiU remain powered to receive ™dio message to RF receiver 60 (or any other similar type 

incoming messages. If the user were to turn off the power of radio card) illustrated in FIG. 5. The radio transport 

during processing of an incoming message, the display 34 header 162, in one embodiment, supports sixteen different 

would turn off to indicate at least partial shut down of the addresses. RF receiver 60 filters and discards any radio 

mobile device 10; however, the incoming message would be 50 messages which do not match any of the wireless addresses, 

processed according to the above-described procedure. In I f a match is observed, then RF receiver 60 has detected a 

this manner, the "power off" signal is trapped and processed radio message potentially addressed to it, and must receive 

when processing of the incoming message is complete and further process the message. 

(unless the processing of the message results in the need to Group addresses bytes 164 and topic filtering bytes 166 

perform a full wake-up). 55 are also provided. A group address, as referred to herein, is 

Another aspect of the present invention allows for selec- a subclass of a wireless address that is used in accordance 

tive enabling and disabling of wireless addresses recognized with the present invention to extend the filtering capability 

by the wireless receiver 27. Referring back to step 106 in of a ^ address. Further, a topic is a subclass of a wireless 

FIG. 7, the processor 62 (FIG. 5) examines the wireless address or group address, which is also provided to extend 

address of information received and discards information at 60 me filtering capability of the wireless address and group 

step 108 that does not pertain to a wireless address associ- address information. 

ated with the mobile device 10. One aspect of the present IT should be noted that information packet 160 arriving at 

invention includes maintaining a list of recognized wireless wireless receiver 27 with an appropriate address may not 

addresses, for example, in memory 64, that the processor 62 have group address bytes 164 and topic filtering bytes 166 

can access when information is received. As stated above, 65 pre -appended thereto. If those bytes are present, however, a 

FIG. 8 is a pictorial representation of a list 150 of wireless driver 200 (FIG. 10) operates to filter the information packet 

addresses. Each wireless address in the list 150 includes an 160 based on the group and topic filtering bytes. 
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The driver 200 implements logic which first examines 
information packet 169 to determine whether any group and 
topic filtering byets are included in information packet 160. 
In one embodiment, the driver 200 supports a library which 
includes a function AnalyzeMessage ( ), The AnalyzeMes- 5 
sage function isolates service group codes and other infor- 
mation in the incoming message. If group and topic filtering 
bytes are present, then the group and topic filtering functions 
must be performed. 

In one embodiment, mobile device 10 includes a memory 10 
which contains a group table. Briefly, the group table con- 
tains entries of service groups, each of which can be 
associated with any suitable address. Also, there can pref- 
erably be any suitable, number of service groups associated 
with one address. Thus, in one embodiment, group entries in 
the group table are sorted by address numbers, then by 15 
service group codes. 

If group or topic filtering bytes are detected, then the 
driver 200 searches the group table to determine whether the 
service group code detected in information packet 160 is 
listed in the group table, and whether it is active or inactive. 20 
If the service group code is not found in the table, or if it is 
found but it has been deactivated (or disabled), then the 
driver 200 discards the information packet 160 and no 
further processing is done with respect to that message. 
However, if driver 200 determines that the group address 25 
bytes 164 are included in the group table, then it is deter- 
mined that the message was intended for that particular 
mobile device 10 and further processing continues on topic 
filtering bytes 166, if present. Topic filtering is discussed in 
greater detail below. 30 

Since all of the group and topic filtering is done at the 
level of driver 200, it occurs quite low in the protocol stack, 
or system architecture, of mobile device 10. Thus, filtering 
occurs early on in the process and the storage space required 
for the address and message is quite low. In addition, since 35 
the driver 200, itself, performs much of this filtering, the 
group and topic filtering bytes allow any application running 
on mobile device 10 to pass correct filtering information 
down to the group and topic tables for filtering at the level 
of driver 200. This significantly improves power consump- 40 
tion over previous designs because the messages do not need 
to be received, processed, and passed all the way up to the 
application level in the protocol stack, or architecture, of 
mobile device 10 before being filtered. 

FIG. 10 illustrates hardware and software modules for 45 
filtering input messages based on topic filter bytes 166 prior 
to storage or delivery to a higher level application module. 
Generally, in the exemplary embodiment, the modules 
include the driver 200 that receives messages of the exem- 
plary format described above from the wireless receiver 27. 50 
If the input message includes topic filter bytes 166, driver 
200 executes a topic filter module 204 that compares the 
topic filter bytes 166 with previously stored content filter 
data 206. If the topic filter bytes 166 correspond to user 
preferences as indicated by the content filter data 206, driver 55 
200 passes the information upwardly in the mobile device 
architecture for storage in store 18 and/or use by higher level 
application modules indicated at 208, 209 and 210. In the 
embodiment illustrated, a routing module 212 is provided to 
receive at least the data 170 from the driver 200. Routing $0 
module 212 forwards the input message to store 18 or any 
of the application modules 208-210 as required or given by 
routing header 168 (FIG. 9). Communication between driver 
200 and routing module 212 can be implemented using 
standard APIs. 65 

FIG. 11 illustrates a method 220 for obtaining and creat- 
ing content filter data 206 used to filter input messages or 
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information packets 160. At step 222, user preferences are 
obtained for the content that will be filtered. Generally, the 
user provides individual indicators, a range of indicators or 
a set of indicators that the user would or would not like to 
receive information on. For example, the indicators can 
comprise key words, characters, numbers, etc., that have 
typically been previously agreed to with the information 
source provider 13 to be used for filtering content. If desired, 
a hashing function can be used for all packets received, or 
can be selected based on the type of content information 
which will be received. For instance, a first hashing function 
can be used for ASCII strings while other hashing functions 
can be used for numeric data, non-ASCIIU Unicode data, 
binary data, etc. In another application, indicators in the 
topic filter bytes 166 can be zip code data allowing region- 
specific filtering to be received. In yet another application, 
the topic filter bytes can be mnemonic codes for "channels" 
of broadcast information, allowing the user to subscribe or 
unsubscribe to specific channels. Referring back to FIG. 10, 
a user interface module 228 obtains the indicators from the 
user. The user interface module 228 can be accessed by or 
incorporated into application modules 208-210. 

Having obtained the user preferences for content filtering 
at step 222, content filter data 206 is created at step 230. In 
one embodiment, content filter data 206 is organized as a 
function of wireless addresses or group addresses in order 
that content filtering can be performed as a function of the 
wireless address or group address of the incoming message. 
In the embodiment illustrated, a plurality of filter data tables 
232A, 232B, 232 C and 232D are shown, wherein each filter 
data table 232A-232D is associated with a wireless address 
or a group address. In one embodiment, the filter data tables 
232A-232D can simply contain the indicators provided the 
user. However, in order to conserve memory resources, it 
may be advantageous to transform the indicator into another, 
smaller representation. For example, a translation function 
can be implemented wherein a unique integer (within a 
small range) is obtained for each indicator. The unique 
integer can then be stored in the corresponding filter data 
tables 232A-232D. In a further embodiment, each of the 
filter data tables 232a-232D can comprise a bit-array where 
the unique integer is used as an offset into the array and 
wherein each bit, if set ("1"), indicates that the correspond- 
ing content is desired, and wherein if the bit is reset ("0"), 
the corresponding content is not desired. In yet a further 
embodiment, a hashing function can be used if the range of 
unique integer numbers becomes too large. However, since 
the integers will no longer be unique, undesired content 
information may be obtained if the topic filter bytes 166 in 
the incoming message correspond to an integer of desired 
content information. 

At the step 236, content filter data 206 is stored in memory 
accessible to driver 200. In one embodiment, content filter 
data 206, or a smaller portion such as one or more filter data 
tables 232A-232D is created in memory 244 accesible by 
user interface module 228, and then transferred to memory 
accessible to driver 200 in its entirety, for example, though 
driver 200. Alternatively, driver 200 can allocate necessary 
memory wherein content filter data 206 or portions thereof, 
such as filter data tables 232A-232D, are incrementally 
updated or populated according to the user preferences. 

FIG. 12 illustrates a method 250 for processing an incom- 
ing message that has been transmitted on a wireless address 
or group address recognized by mobile device 10. At step 
252, driver 200 receives the incoming message. At step 254, 
driver 200 analyzes the message using the AnalyzeMessage 
( ) function described above to ascertain if the incoming 
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message includes topic filter bytes 166 for content filtering. table is provided at "dwNumEntries". Driver 200 or user 

If the message does not contain topic filter bytes 166, interface module 228 allocates necessary space in memory 

operational flow proceeds to step 256 whereat the driver 200 for content filter data 206, or memory 244, respectively, and 

passes the incoming message to store 18, higher application provides back to the application module a handle or a pointer 

modules 208-210 or, in the embodiment illustrated, to s a t "phFTableMt should be noted that the filter data table can 

routing module 212. be create first in memory 244 and then transferred to 

If, however, the incoming message includes topic filter memory accessible by driver 200. 

bytes as detected at step 254, operational flow continues to In me embodiment illustrated, this API also can include an 

step 258 whereat driver 200 provides the topic filter bytes mput denoted herein as "wftFilterType", which can be used 

166 to topic filter module 204 Topic filter module 204 10 to predefined mter Wions. For instance, a first 

compares the topic filter bytes 166 with content filter data y ^ can be ided (o indicate ^ aU m s irlns . 

206. In the embodiment i^ated I^R^ mocM( \ 2 ° 4 mitted on the wireless address or group address or group 

accesses the filter data table 232A-232D that corresponds to * JA j i u jj* 

,i * * jj £. , address will be accepted. A second value can be provided to 

the wireless address or group address upon which the ..... « ,i L • * j * n_- j i 

incoming message was transmitted. If filter data tables indicate that all messages will be rejected. A third vahie can 

232A-232D have been created using a hashing function, 15 be provided to mmcate that a preselected mtenng function, 

topic filter module 204 operates the hashing function upon such 35 hashm S ^cOon will be used. (Other filtering 

the topic filter bytes 166 so as to ascertain if the incoming functions can include an individual, set or range of content 

message pertains to desired content. It should be noted that information.) Afourth value can be provided to indicate that 

the topic filter bytes 166 can be in a compressed and/or in a a particular type of data needs to be received first before 

protocol format such as UNICODE in order to transmit the 20 content filtering will begin. The latter is probably best 

data packet 160 over a wireless network. In such cases, topic illustrated by an example. In co-pending application entitled 

filter module 204 operates upon the topic filter bytes 16 6 as "CHANNEL DEFINITION ARCHITECTURE 

necessary in order to make a comparison with content filter EXTENSION", a system and method are described wherein 

data 206. It should also be noted that the same hashing Web or Internet is rendered on a mobile device using a 

function need not be used for each filter data table 2 s channel definition format (CDF) file, a set of script files and 

232A-232D. Rather, different hashing functions can be used a set of data files. Briefly, navigation of the content on the 

for one or more of filter data tables 232A-232D. Topic filter mobile device is performed using the CDF file which 

module 204 can maintain a table of hashing functions includes references to the script files and the data files. When 

according to wireless addresses or group addresses and one particular page of content is to be displayed, a script file 

access this table based on the wireless address or group 30 ^ accesse d and is used to operate upon the data file in order 

address that the message was transmitted on. l0 reDder the desired information. This architecture allows 

Topic filter module 204 provides as an output an indica- wireless updates of data files, because, typically, only the 

tion of whether or not the incoming message relates to the data files will change with time. However, if desired, the 

user's preferences. If the incoming message pertains to CDF files and the script files can be also be updated 

desired content information as compared to content filter 35 wirelessly. Each of the data files, script files and CDF files 

data 206, operational flow continues to step 256 whereat have associated identifiers. 

driver 200 forward at least the data portion of the message i n sllcn a system, content filtering can be provided as a 

further in the architecture of the mobile device 10 as function of particular data to be displayed. For instance, the 

discussed above. Otherwise, operational flow proceeds to user mav on \y wa nt information regarding football or base- 

step 260 whereat the message is discarded by driver 200. 40 ball articles (which are associated with certain identifiers), 

Although illustrated wherein functions of driver 200 and but not want any articles related to hockey (which are 

topic filter module 204 have been separated, it should be associated with another identifier). Using topic filter bytes 

understood that these functions can be performed by driver itffi ^ described above, the user can filter the data files 

200 alone, or divided up among even more than the two accordingly using the identifiers. However, in this system, as 

modules illustrated in the exemplary embodiment. 45 discussed above, in order to display the data files, it is 

In one embodiment, APIs are provided to allow applica- necessary that the user receive the CDF file so that upon 

tion modules 208-210 to operate with driver 200 in order to rendering, the application module will know which script 

select operational parameters and/or access content filter file to use to render the data. The fourth value can be used 

data 206. Exemplary APIs include: to indicate that the CDF file must be received before any 

IsGroupTagRegistered (LPWSTR sxGroupTag, BOOL 50 content filtering will be performed. Upon receipt of the CDF 

*fResult, LPDWORD pdwDevice) This API allows an file, this API can then be used to initiate content filtering by 

application module to query driver 200 to ascertain if providing, for example, the third value, 

content filtering will be performed on an address or a SetHash Value (Handle hFTable, LPWSTR szValue) 

group address. As discussed above, driver 200 can This API is used in accordance with a filter data table 

maintain a table or other list indicating enablement or 55 comprising a bit-array that is set according to a hashing 

disenablement of content filtering as a function of function. In particular, the hashing function is applied to the 

address or group address irrespective of the existence input given by "sz Value" wherein the filter data table indi- 

of a filter data table corresponding to the address or catedby a handle or a pointer "hFTable" is updated to reflect 

group address. This allows easy enabling or disen- the desired content. 

abling of content filtering as a function of an address or 60 SetPreference (HANDLE hFTable, DWORD 

group address. This API returns a "true" or a dwPreferences) 

"false "indication in "fResult" as to whether the group This API allows additional information to be stored for 

address as given by "szGroupTag" is registered or not. each of the filter data tables 232A-232D. Referring back to 

CreateFilterTable (HANDLE *phFTable, DWORD FIG. 10, the additional information is indicated at 270A, 

dwNumEntries, WIS _FILTER_TABLE wftFilterType) 65 270B, 270C and 270D, respectively, for each of the filter 

This API allows an application module to create a filter data tables 232A-232D. In one embodiment, the additional 

data table wherein the approximate size or entries of the information 270A-270D can store global preferences that 
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will be applied to the incoming message if transmitted 
pursuant to the wireless address or group address. For 
example, data filter table 232A can correspond to football 
and baseball articles provided on a selected "channel". If 
desired, an application module can also store a value in 
portion 270A indicating that only text information will be 
provided from driver 200 whereas, for example, data per- 
taining to images will be discarded. In the embodiment 
illustrated, topic filter module 204 accesses additional infor- 
mation 270A-270D when the corresponding filter data 
tables 232A-232D are accessed. This information is pro- 
vided to the driver 200 where the message is further filtered 
by additional information 270A-270D. In an alternative 
embodiment, all filtering functions can be performed by 
topic filter module 204 whereby driver 200 receives only 
that portion of the message that will be forwarded to higher 
level modules of the mobile device 10. 

RegisterFilterTable (HANDLE hFTable, LPWSTR 
szGroupTag, LPDWORD pdwDevice) 

This API associates a data filter table with a selected 
address or group address. As discussed above, in one 
embodiment, the filter data table can be created in higher 
level memory 244 associated with application modules 
208-210. This API will copy the created data filter table (and 
associated additional information, if present) into memory 
accessible by driver 200. It should be noted that this API also 
allows an application program to disassociate a data filter 
table from a wireless address or a group address. In the 
embodiment illustrated, a "null" value for "hFTable" will 
cause driver 200 to disassociate the filter data table in 
memory accessible by it for the address or the group address 
given by "szGroupTable". 

DestroyFilterTable (HANDLE hFTable) 

This API releases the high level memory 244 accessible 
by the application program module to create the filter data 
table. It should be noted that this API does not disassociate 
the data filter table from the address or group address at the 
level of driver 200. 

The following provides exemplary architecture and appli- 
cation program interfaces (API) for a Windows CE® mobile 
device. 

1.1.1 Overview 

Wireless Services for Windows CE® defines a hardware, 
device drivers, and overall architecture for the incorporation 
of message -based radio into a Windows CE® device. The 
goal is to create a framework within which applications, 
system services and hardware all remain modular with 
respect to each other, thus providing the environment for a 
wide range of applications. 

This appendix addresses what support the device drivers 
need to provide to meet the following requirements: 

1. Power saving achieved by not waking up the whole 
system. 

2. Doing background processing without turning on video 

1.1.2 Terminology 



Device 

Radio 

OEM 



IHV 



Windows CE ® hardware (e.g. Palm PC, Auto PC) 
Radio HW for a device (e.g. a paging card) 
Original Equipment Manufacturer - In this 
document this term refers to the device 
manufacturers 

Independent HW Vendor - In this document IHV 
refers to the radio manufacturer (who develops 
the HW and/or device driver) 
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-continued 



HAL 



LCD and 
VIDEO 



Hardware Abstraction Layer. This is implemented 
by each OEM to abstract their HW 
implementations from the Windows CE ® operating 
system. 

These two terms have been used interchangeably 
and refer to the display panel on the device. 



1.1.3 Overview 

A typical radio device listens to the radio transmissions 
and determines if there is a message for the user. This 
determination is based on one or more 'addresses* that are 
programmed in the radio receiver or hardware (HW). The 
radio HW is powered independently (i.e., it is powered even 
when the Windows CBB> device is powered down) and the 
radio HW carries out the lowest level of filtering without 
requiring the Windows CE® device to be powered on. This 
achieves some level of power savings since radio HW 
typically require only a fraction of power compared to the 
Windows CE<E> device. 

Wireless Information Services for Windows CE® pro- 
vides for additional levels of filtering that may or may not be 
carried out in the radio HW. If the radio HW is separately 
powered and has enough logic to do additional filtering 
independent of the device CPU, then it will not cause major 
power drain from the device power supply. However, it is 
expected that the majority of the radio HW will be in the 
Compact Flash card type II form factor (a form factor for 
most devices) and will not have separate power or CPU due 
to size constraints. These cards, therefore, will cause a 
wakeup of the device so that some processing is carried out 
in the device driver. 

Another way to achieve power saving is not to wakeup the 
system for each message but to buffer them for group 
processing at a later time. The radio HW may not have 
enough memory and to use the Windows CE© device 
memory for this purpose will ordinarily require the device to 
be woken up to run the device driver code that copies 
message from the radio HW to the system memory. In this 
case we want the system to be up for a very short duration 
and there is no need for the display and other subsystems to 
be powered on. 

Thus, the power saving goals can be summarized as: 

System comes up quickly and stays powered on for as 
little time as possible 

The LCD is not turned on until it is needed 

System shuts down as soon as possible (currently, once 
the system is up, it does a time out of the order of 1-5 
minutes to shutdown) 

To achieve the above goals, Win CE Radio device drivers 
support a state called Partial Wakeup state. This refers to the 
device state just after wakeup where HAL has initialized but 
the kernel and file system are not fully initialized. The 
objective is to do some processing in this state to filter out 
unwanted messages and shut down the system as soon as 
possible, ideally from the partial wakeup state itself. 

1.1.4 Driver Support for Partial Wakeup 

This section describes what support needs to be provided 
in the driver. 

1.1.4.1 RIO_lnit() 

During system initialization, radio driver initialization 
function RIO_Jnit( ) is called. In addition to the other 
initialization, it should call a MS supplied function called 
1.1.6.1 RegisterWakeup( ) and supply the address of a call 
back function as parameter. The call back function (called 
CheckAndProcessRadioWakeup( ) in this document) is 
described below. 



05/24/2004, EAST Version: 1.4.1 



US 6,289,464 Bl 



19 



See section 0 for sample code for RIO_init( ) function. 
Section 0 describes RegisterWakeup( ) function that does 
the following: 

1. Calls VirtualAlloc( ) to allocate needed memory 
space. This space will be used to store pointers to 
buffers for radio and other data (e.g. data for filtering 
functions). This memory is referred to as Radio 
Control Block. 

2. Makes the kernel call to lock the driver code and 
allocated buffers in memory. 

3. Calls HAL IOCTL calls and registers a function in 
driver space that will be called by HAL during warm 
boot when the wakeup source is radio (this function, 
called CheckAndProcessRadioWakeup( ) in this 
document, determines if the wakeup should continue 
or not). HAL maintains a data structure for each 
device driver to store this function pointer. 

1.1.4.2 Registered wakeup callback function 
The radio driver is expected to supply a function which 
will be called during the system wakeup sequence from 
HAL. This function executes in the partial wakeup state and 
therefore has many limitations and requirements (described 
later). The main purpose of this function is to achieve power 
savings for the device. Power saving is achieved in many 
ways as listed below: 

The function could simply read the data off the radio HW 
and buffer it in the memory blocks for later processing. 
It could also implement low level filtering (e.g. group 
level filtering, if the radio HW is not capable of doing 
it). In this case the function returns a value indicating 
that system wakeup is not required (in this scenario this 
function acts like an interrupt service routine, quickly 
servicing the radio HW and shutting down the system 
as soon as possible) 
If the system buffers are full, the function could return a 
value indicating to the HAL that a system wakeup is 
required but there is no need to power the display. In 
this scenario, the system wiE wakeup and execute 
message router and other components that process the 
messages and most likely will shut down the system 
after processing is complete. 
If the data is high priority (e.g. a personal page), the 
function should return a value indicating to the HAL 
that a full system wakeup is required because this 
message will most likely cause a user notification. 
1.1.5 Data Structures 
1.1.5.1 Radio control block 

The radio control block data structure is maintained by 
HAL. A pointer to the radio control block is passed to the 
registered function (called 1.1.7.1 
CheckAndProcessRadioWakeup( ) in this document). The 
radio control block holds pointers to memory blocks that 
contain data or code. These memory blocks are allocated 
using Virtu alAlloc( ) function, are locked down so that they 
are accessible during partial wakeup state, and are accessed 
using physical addresses. 

The radio control block is an array of RADIO_BLOCK 
which is defined below: 
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-continued 



DWORD dwSizc; // Size of block 
} HRADIO_BLOCK, *LPHRADIO JLOCK; 



The block can be either a pointer to code or a pointer to 
data as determined by the dwld field. The Ids are generated 
using macros defined in the next section. 

1.1.5.2 Block ID Macros 

The radio control block stores pointers to code or data that 
needs to be accessed during partial wakeup state. The entries 
are tagged using an id, which is generated using one of the 
macros defined below: 

H RAD 1 0_MAKE_D RI VER_ID (Pari, Par2) 

Generates an id for a driver function or data block. Pari 
can be either HRADIO __DATA (for defining a data 
block pointer) or HRADIO_CODE (for defining a 
function pointer). Par2 is an unsigned 16-bit value, 
HRADIO_MAKE _SYSTEM JD (Pari, Par2, Par3) 
Generates an id for a known system function or data 
block. These ids are used internally by the system 
and should not be used by the device drivers. Pari 
can be either HRADIO_DATA (for defining a data 
block pointer) or HRADIO_CODE (for defining a 
function pointer). Par2 and Par3 have the following 
meanings: 



HRADIO_WAKEUP 



HRADIO_ANALYZE MSG 



0 HRADIO JTLTER 



Address Group 



Pointer to the partial 
wakeup call back function 
or data 
Pointer to the 

AnalyzeMessage( ) function 
or data 

Pointer to the 

FilterMessage( ) function or 
data 

Pointer to application 
niter function or data for 
the given address/group 
combination 
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1.1.6 Function Reference — MS Supplied Functions 

1.1.6.1 RegisterWakeup( ) 

This function does the following: 

Creates the Radio control block (Virtu alAlloc( ), lock it, 

register with the HAL) 
Makes HAL IOCTL call to register the wakeup callback 

function (which will be called by HAL during partial 

wakeup sequence) 
Makes HAL IOCTL call to register AnalyzeMessage( ) 

function (which deciphers the message header) 
Makes HAL IOCTL call to register FilterMessage( ) 

function (which invokes the application level filtering 

functions) 
Syntax 



typedef struct _Jiradio_block { 

DWORD dwld; // Block ID 

DWORD PAddr; // Physical address of block 

DWORD VAddr; // Virtual address of block 
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LPHRADIO_BLOCK RegisterWakeup( 
BYTE Deviceld, 
BYTE NumBlocks, 
LPVOID pWakeupFn, 
DWORD dwWakeupFnSize) 



05/24/2004, EAST Version: 1.4.1 



US 6,289,464 Bl 



21 



22 



Parameters 
Deviceld 

Identifies the device controlled by this driver (this 
parameter is derived from the parameter passed to 
the RIO_Jnit( ) function) 
NumBlocks 

Number of additional radio control block entries 
needed by the driver (driver will need one entry 
for each buffer or function it intends to use during 
partial wakeup state). This does not include sys- 
tem required entries, e.g. the partial wakeup call- 
back function etc. 
pWakeupFn 

Pointer to the partial wakeup callback function. 
dwWakeupFnSize 
Size in bytes of the partial wakeup callback function. 
If not used, pass a 0 value. 
ReturnValue 

Returns pointer to the radio control block if successful, 
NULL otherwise, 
1.1.6.2 LocateAndCallAnalyzeMessage( ) 
This function locates and invokes the AnalyzeMessage( ) 
function in partial wakeup state (driver can call the 
AnalyzeMessage( ) function directly in other places). 
Syntax 



BOOL LocateAndCallFUterMessage ( 
VOID 'pMsg, 
DWORD dwMsgLen, 
BYTE Address, 
BYTE GroupCodc) 



Parameters 
pMsg 

Pointer to the message bytes. 
dwMsgLen 

Length of the message. 
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Address 

Address number this message came on. 
GroupCode 

Group code this message came on. 
Return Value 

Returns TRUE if message should be kept, FALSE if it 

should be discarded. 
1.1.6.4 RegisterBlock( ) 

Allocates a memory block, locks it down, and creates an 
entry in the radio control block for it. Then data from the 
supplied buffer is copied into this newly allocated memory 
block. 

Syntax 

LPHRADIO_BLOCK RegisterBlock(BYTE Deviceld, 
DWORD dwBlockld, LPBYTE lpbData, DWORD 
dwDataLen) 

Parameters 
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BOOL LocateAndCallAnalyzeMessage ( 
VOID *pMsg 
DWORD dwMsgLen, 
BOOL "pfDiscard, 
BYTE *pGroupCode) 



Parameters 
pMsg 

Pointer to the message bytes. 
dwMsgLen 

Length of the message. 
pfDiscard 

Receives a BOOL value indicating whether the mes- 
sage should be discarded or kept. 
pGroupCode 

Receives the Group code. 
Return Value 

Returns TRUE if message had a valid WS header, FALSE 
otherwise. When it returns TRUE, pGroupCode 
receives the group code and pfDiscard receives a 
BOOL value indicating whether the message should be 
kept or not (TRUE-discard). 

1.1.6.3 LocateAndCallFilterMessage( ) 

This function locates and invokes the application level 
filtering mechanism. 

Syntax 
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Device Id 


The block will be added to the radio control 




block for this device. 


dwBlockld 


Block Id to be assigned (This id must be 




output of macros defined in 0) 


lpbData 


Pointer to the data that will be copied in a 




newly allocated memory block. 


dwDataLen 


Length of the data (this is the size of the 




newly allocated memory block) 
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ReturnValue 

Null is returned if data block can't be created, pointer to 

the created radio block is returned otherwise. 
Remarks 

The dwBlockld also indicates whether the block is a code 
block (function) or data block (buffer). 

1.1.6.5 LocateBlock( ) 

This function searches the radio control block for the 
given block id. 
Syntax 

LPHRADIO_BLOCK LocateBlock (BYTE Deviceld, 
DWORD dwBlockld) 
Parameters 
Deviceld 

The block will be searched in the radio control block 
for this device. 
dwBlockld 

Block Id to be assigned (This id must be output of 
macros denned in 0) 
ReturnValue 

Returns pointer to radio block if ID found, else returns 
NULL 

1.1.6.6 Busy() 

This function increments or decrements the system busy 
counter. 
Syntax 

WORD Busy(BYTE State) 
Parameters 

State 

If TRUE, increments the busy counter, FALSE dec- 
rements busy counter. 
ReturnValue 

Returns current value of system busy counter. 
1.1.6.6 Video( ) 

This function turns the video on or off. 
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Syntax 

BOOL Video(BYTE State) 
Parameters 

State 

If TRUE, turns video on. FALSE turns video off. 
ReturnValue 

Returns TRUE if operation completed, FALSE otherwise. 

1.1.7 Function Reference — IHV Supplied Functions 

1.1.7.1 CheckAndProcessRadioWakeup( ) 

This function is statically part of the radio driver but is 
called by the HAL during warm boot. The main purpose of 
this function is to check if the radio device needs some 
service and whether this service can be handled within HAL 
or it requires the whole system to be woken up. 

Syntax 



DWORD CheckAndProcessRadioWakeup ( 

DWORD MemPtr Pointer to radio control block 
) 



Description 

This function is called in response to the wakeup interrupt 
from the radio device (RING__INDICATE interrupt). 
This function is called by HAL before the kernel is 
initialized (partial wakeup state), Because of this, this 
function must meet the following criteria: 
The function must be on a page boundary. 
The function will be executed in physical mode 
The function must not call any OS or file system calls. 
The function must not call any other function. (If it 
needs to call other driver supplied functions, they 
must be called via a function pointer table initialized 
during startup. See Error! Reference source not 
found, and Error! Reference source not found, for 
details.) 

The function should read the data from the radio device 
and determine if the data needs to be kept or discarded. If the 
data needs to be kept, it should further determine if it is high 
priority data (see device driver specifications for discussion 
of address and group property flags). High priority data 
needs to be processed immediately and will require a full 
wakeup. Low priority data may be buffered in memory 
allocated during startup. If that memory is full, a full wake 
up is again required to flush that memory. In either case, the 
data is read off the radio device and appropriate return value 
is passed to the HAL. 

The skeleton of this function is: 

read data off the radio HW 

Call AnalyzeMessage( ) to get the group code information 
from the message header 

Do group level filtering (if the HW has not done it) 

Invoke application level filtering mechanism. Do message 
filtering based on the return code. 

if message is to be kept, then buffer it and return appro- 
priate return code 

Since this function is executed during the partial wakeup 
state, it can not make function calls directly. Instead a 
support library has the following two functions to invoke the 
Analyze Message( ) and filter mechanism: 

LocateAndCallAnalyzeMessage( ) — this function 
invokes the AnalyzeMessage( ) function described in 
the device driver specifications. 

LocateAndCallFilterMessage( ) — this function invokes 
application level filtering (to be documented). 
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Return Values 
HRADIO_NOCONTINUE 

The device has been serviced, no need to continue the 
warm boot. An example of this case would be when the radio 
5 device has a new message that can be buffered in the system 
memory (done by this function) and no further processing is 
required. 

HRADIO„CONTlNUE_VIDEO_ON 

The device service needs the system to continue the warm 
to boot with video (the video should be powered on too). An 
example of this case would be when a message is received 
on a priority address that will cause a notification to be 
issued. 

HRADIO__CONTINUE_VIDEO_OFF 
15 The device service needs the system to continue the warm 
boot without video (the video should not be powered on). An 
example of this case would be when a broadcast message is 
received when the system memory buffer is full, so process- 
ing should continue without video so the system buffer can 
20 be flushed. 
Remarks 

The partial call back function is quite similar to the 
interrupt service function (ISR) (also supplied by the driver). 
However, there are some significant differences as outlined 
25 below: 
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Partial wakeup call back 


ISR 


function 


Registered using 


Registered using 


CardRequestIRQ( ) 


RegisterWakeup( ) 


Registered for a specified 


Registered for a driver. 


socket and function pair. 




Interrupt condition cleared 


Call back function needs to 


by Card Services. 


clear the interrupt 




condition. 


Return as quickly as 


Return as quickly as 


possible. If more processing 


possible, can not spawn a 


needed, spawn a thread and 


thread. 


return. 




Kernel and file system 


No kernel or file system 


services available. 


services. 


Always called to handle the 


Called only if the interrupt 


interrupt from the radio HW. 


causes a system wakeup (if 




the system is already up at 




the time of the interrupt, 




only the ISR gets to 




execute). 


Responsible to copy the 


Responsible to copy the 


message from the radio HW, to 


message from the radio HW, to 


analyze it, and to filter it. 


analyze it, and to filter it. 


Can call the MS supplied 


Can call the MS supplied 


functions directly to do 


functions using special 


these. 


indirection methods only. 


Is a normal user-mode 


Is a special function that 


function. 


executes in physical mode and 




has special restriction on it 




(e.g., must be on a page 




boundary, can not call other 




functions, etc) 



1.1.8 Sample Code 
1.1.8.1 R10_Init() 
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HINSTANCE HalLib; 
LPHRADIO _BLOCK HalMem; 
// Since the Register function needs to be located on 
// a page boundary, the following pragma assures that, 
65 DWORD CheckAndProcessRadioWakeup (DWORD); 

^pragma alloc_tcxt (".wakeup", CheckAndProcessRadio Wakeup) 
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-continued 



HalLib - LoadDrivcr (TEXT( 14 riohaLdlO); 
if (HalLib) { 

func = OctProcAddrcss (pRfldioCtl->HalLib, 

TEXT ("RegisterWaJteup")); 
if (func) { 

// Call RegisterWakeupf ) 
HalMem - (LPHRADIO_BLOCK) 

("func) ((DWORD) CheckAndProcessRadioWakeup); 



} 



} 
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holds the size in bytes of the fixed part of the struct 
(i.e., fixed fields and the lengths of the variable 
fields). This field provides a versioning method as 
well and will be used for backward compatibility in 
the future releases. 
In addition, the variable length fields are grouped towards 
the end a length field for each one of them is provided. This 
allows expanding these structures without losing backward 
or forward compatibility. 

1.1.9.3 struct HRADIO_JlEGISTER 

This struct is used for registering a wakeup function. 



1.1.8.2 CheckAndProcessRadioWakeup( ) 



LP BYTE pAddressTag, pGroupTag; 

BOOL {Discard, fGroupFound; 

BYTE GroupCode; 

char *p, buf [1000]; 

BYTE bMsgBuf [MAX_MSG_SIZE]; 

WORD dwMsgSize; 

char address - 1 

// Fill szMsgBuf[ ] with message data from the Radio HW 
// do group filterning 

fGroupFound - LocateAndCallAnalyzeMessage (bMsgBuf, 
dwMsgsize, 

&fDiscard, &GroupCode); 

if (fGroupFound) { 
if (fDiscard) { 

// discard message 

return HRADIO_NOCONTTNUE, 

} 

II Search driver data structure for group info 
relating to 

// the address this message came on and the group code 
// (returned by the AnalyzeMcssage( ) above 
// if GroupCode is not found or it is disabled then 
// also discard the message 

if (ILocateAndCallFilterMessage (bMsgBuf, dwMsgSize, 
Address, GroupCode)) 

{ 

// discard message 

return HRADIO_NOCONTTNUE; 

} 

// here buffer the message and return 
HRADIO^OCONTINUER 

// if buffer full then return HRADIO_CONTINLJE_ VIDEO. 
}else{ 

// treat as a normal page message (cause full wakeup, 
etc.) 



OFF 



} 



return HRADIO_CONTINUE_VIDEO_OFF; 



1.1.9 Type Definitions 

This section defines the types used in the driver API. 

1.1.9.1 Basic Types 

The following basic types are used: 
BYTE Unsigned 8-bit 
WORD Signed 16-bit 
DWORD Signed 32-bit 

1.1.9.2 Complex Types (structs) 

All structures have the following three fields at the 
beginning: 

WORD wOperationCode 

Indicates what operations needs to be performed. This 
field also determines the rest of the struct. 
WORD wStructSize 

Each struct has fixed size fields followed by the length 
of the variable fields. The variable fields follow in 
the same order as their lengths. The wStructSize field 
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Size 


Field 


2 


WOperationCode 


2 


WStructSize 


4 


DwMemPtr 


1 


Device 
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WORD wOperationCode 

HAL_IOCTL_CMD_REGISTER_WAKEUP_ 
FUNCTION 
WORD wStructSize 

sizeof(HRADIO_REGISTER) 
DWORD dwMemPtr 

Pointer to a memory block (RMB). The second 
DWORD of this memory block contains a pointer to 
the function that will be called by HAL during 
wakeup to determine if power on sequence should 
continue or not. 
BYTE Device 

Device number (This is how HAL distinguishes one 
device's RMB from another). 
1.1.9.4 struct HRADIO__FLAG 
This struct use used for operations on the HAL flags. 





Size 


Field 




2 


wOperationCode 




2 


wStructSize 


45 


2 


wFlag 



WORD wOperationCode 

One for the following values: 
HRADIO__CMD__FLAG_SET 
HRADIO_CMD_FLAG_CLEAR 
HRADIO_CMD _FLAG_GET 
WORD wStructSize sizeof(HRADIO JLAG) 
WORD wFlag A code indicating which HAL flags is 
affected by the requested operation. Values are: 
HRADIO_FLAG_V1DEO_STATE 
H RADIO _FLAG_SYSTEM_BUSY 
1.1.9.5 struct HRADIO__LOCK 

This struct use used for operations on locking and unlock- 
60 ing memory. 



Size 



Field 
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wOperationCode 
wStructSize 
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-continued 


Size 


Field 


4 


dwMcmPtr 


4 


dwSizc 



WORD wOperationCode 

One for the following values: 
HRADIO_CMD_LOCKPAGE 
HRADIO_CMD_UNLOCKPAGE 
WORD wStructSize 

sizeof(HRADIO_LOCK) 
DWORD dwMemPtr 

A virtual pointer to memory to be locked or unlocked. 
DWORD dwsize 

The total number of bytes to be locked or unlocked. 
1.1.10 HAL Flags 

The following flags form part of the HAL: 
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Flag 



Type Meaning 



HAL_fVideoState Bool 



HAL_SystemBusy Counter 



Set if the video is currently 

powered on, reset otherwise. Set 

on cold boot. (When the flag is 

set using HRADIO_CMD_FLAG_SET 

command, the video is turned ON. 

When it is reset, the video is 

turned off). 

This needs to be implemented as a 
counter (at least one byte). If 
non-zero, HAL will trap power off 
button to prevent system from 
shutting down. 

HRADIO_CMD_FLAG_SET command 
increments the counter, 
HRADIO_FLAG_CLEAR decrements it. 
Initialized to 0 on cold boot. 
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1.1.11 HAL IOCTL calls 

In Windows CE® systems, HAL supports IO Control 
calls to perform operations that are specific to their hard- 
ware. Most OEMs already implement the following IOCTL 
call for other services. 

Syntax 
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pBufOut 

Points to the buffer used to transfer the output data. 
dwLenOut 

Specifies the maximum number of bytes in the buffer 
specified by pBufOut 
pdwActualOut 

Points to DWORD buffer the function uses to return the 
actual number of bytes received from the device. 
Return Value 

Returns TRUE if the HAL successfully completed its 
specified I/O control operation, otherwise it returns 
FALSE. 

1.1.11.1 HRADIO_CMD_REGISTER 
Syntax 



HRADIO_REGISTER CmdBuf; 
HANDLE hRegister; 

CmdBuf.wStructSize - sizeof(HRADIO_REGISTER); 
CmdBuf.dwOperationCode - HRADLO_CMD__REGISTER; 
CmdBuf.MemPtr = . . . ; (NULL for deregistering) 
CmdBuf. Device - . . . ; 
BOOL OemIOControl( 

DWORD dwCode - IOCTL_HAL__RADIO_CNTRL 
PBYTE pBufln - & CmdBuf 
DWORD dwLenln - sizeof(CmdBuf) 
PBYTE pBufOut - AhRegister 
DWORD dwLenOut - sizeof(HANDLE) 
PDWORD pdwActualOut - &dwWriteBytes 



); 



Operation 

This call registers a radio memory block (RMB) that 
contains a pointer to the wakeup function that is called 
during HAL power on processing. If the MemPtr 
member is NULL then the call does de-registration. 
The output buffer returns a handle to the RMB (address 
of the HAL data structure where the device memory 
block was saved). 

Remarks 

The function supplied must be statically bound to the 
driver code and small enough to fit within a memory 
page. 

1.1.11.2 HRADIO_CMD_FLAG_xxx 
Syntax 
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HRADIO__FLAG CmdBuf; 
CmdBuf. wStructSize = 8; 

CmdBuf. wOperationCode = HRADIO_CMD__FLAG_jexx; 
50 CmdBuf. wFlag «... 

BOOL OemIOControI( 

DWORD dwCode « IOCTL_HAL_RADIO_CNTRL 
PBYTE pBufln a & CmdBuf 
DWORD dwLenln = sizeof(CmdBuf) 
PBYTE pBufOut - AdwOldFlagValues 
55 DWORD dwLenOut - sizeoffdwOldFtagValues) 

PDWORD pdwActualOut - &dwWriteBytes 

); 



BOOL OEMIOControl( 
DWORD dwCode 
PBYTE pBufln 
• DWORD dwLenln 
PBYTE pBufOut 
DWORD dwLenOut 
PDWORD pdwActualOut 

); 



Parameters 
dwCode 

Specifies a value indicating the I/O control operation to 
perform. The code used will be IOCTL__HAL_ 
RADIO„CNTRL. 
pBufln 

Points to the buffer containing data that is input to the 
HAL. 

dwLenln 65 
Specifies the number of bytes of data in the buffer 
specified for pBufln. 



Note: pBufOut, dwLenOut, and pdwActualOut are used 
for GET operation only. Set them to NULL for other 
operations. 

Operation 

The operation depends upon the operation code stored in 
dwOperationCode member and is described below: 
HAL_IOCTL_CMD_SET_FLAG 
If the indicated flag is a Boolean flag then set it to 
TRUE. If it is a counter flag, then increment it. 
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HAL_IOCTL_CMD_RESET_FLAG 

If the indicated flag is a Boolean flag then set it to 
FALSE. If it is a counter flag and is non-zero, then 
decrement it. 
HAL_IOCTL_CMD_GET_FLAG 

Value of the indicated flag is returned in pBufOut. For 
simplicity, the flag value is always returned as a 
DWORD (so pBufOut must be large enough to hold 
at least one DWORD). 
Additional processing for HRADIO_FLAG_VIDEO__ 
STATE 

If the flag changes its state because of a set or a reset 
command, the video needs to be turned on or off to 
correctly reflect the new state of this flag. For 
example, if the HAL_fVideoState is 0 and a HAL„ 
IOCTL_CMD_FLAG_SET is issued on this flag, 
then the video needs to be turned on. If the flag was 
already set to 1 (hence the video is already on), then 
this set command will have no effect and there is no 
need for any additional processing (the video is 
already ON). 
Remarks 

The HAL flags are accessible to the drivers directly (they 

don't need to make these IOCTL calls). 
1.1.11.3 HRADIO_CMD_LOCKPAGE 
Syntax 



HRADIO_LOCK CmdBuf; 
CmdBuf. wStructSizc ~ 12; 

CmdBuf.wOpcratiotiCode = HRADIO_CMD_UNLOCKPAGE; 
CmdBuf.dwMcmPtr = previous value returned from 

HRADIO_CMD__LOCKPAGE; 
CmdBufdwSize = previous value used with 

HRADIO_CMD_LOCKPAGE; 
BOOL OemIOControl( 

DWORD dwCode » IOCTL__HAL_RA D [0_CNTRL 

PBYTE pBufln « &CmdBuf 

DWORD dwLenln « sizeof(CmdBuf) 

PBYTE pBufOut - NULL (not used) 

DWORD dwLenOut = 0 (not used) 
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HRADIO_LOCK CmdBuf; 
CmdBuf.wStructSizc = 12; 

CmdBuf. wOperationCode - HRADIO_CMD_LOCKPAGE; 
CmdBuf.dwMemPtr = &buf; 
CmdBuf.dwSize = sizeof(buf); 
BOOL OemIOControl( 

DWORD dwCode - [ OCTL_HAL_RADIO_CNTRL 

PBYTE pBuflti - &CmdBuf 

DWORD dwLenln = sizeof(CmdBuf) 

PBYTE pBufOut = PHYSICAL ADDRESS OF LOCKED PAGE 
DWORD dwLenOut - sizeof(DWORD); 
PDWORD pdwActualOut « &dwWiiteBytes 

); 



Operation 

This operation locks down the memory pointed to my 
dwMemPtr. The number of pages locked will be deter- 
mined by the page size and the value of dwSize. The 
value returned will be the physical address of the first 
byte pointed to dwMemPtr. This value will normally be 
adjusted to be not cached and accessible at initial power 
on. 

1.1.11.4 HRADIO_CMD„UNLOCKPAGE 
Syntax 
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-continued 



PDWORD pdwActualOut = &dwWritcBytcs 

); 



Operation 

This operation unlocks the memory pointed to my 
dwMemPtr. The number of pages unlocked will be 
determined by the page size and the value of dwSize. 
This function is used to unlock previously locked 
memory. 

1.1.12 HAL LCD Changes 

The LCD initialization code needs to check the wakeup 
source and determine if the LCD should be turned on or not. 
If HAL_JMdeoRequest flag is implemented, then the pro- 
cessing would be as follows: 
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if (HAL_fVideoRequest) { 

Continue normal initialization sequence (the LCD 

is turned on). 
} else { 

Continue initialization, sequence without actually 
powering on the LCD. 

} 



The LCD code also needs to correctly set HAL_ 
fVideoState flag: TRUE when the LCD is powered ON, and 
FALSE when it is not. 

1.1.13 HAL Touch Screen Considerations 
If the touch screen can not be turned of when the video is 
turned off, then the touch interrupt should be ignored if the 
video is currently off (ie, HAL_fVideoState==FALSE). For 
devices that support the touch screen to turn on the device, 
then the video should be turned on, and the touch interrupt 
event should be discarded. This can be done by the following 
code: 



if (HAL_fvideoState — FALSE) { 
HRADIO_FLAG CmdBuf; 
CmdBuf.wStructSizc - sizeof(HRADIO_FLAG); 
CmdBuf. wOperationCodc = HRADIO_CMD_FLAG_SET f 
CmdBuf. wFlag = HRADIO_FLAG_VIDEO_STATE; 
OemIOControl(10Cn JL _HAL__RADIO_CNTRL, 
&CmdBuf, sizeof(CmdBuf) 
NULL, 0 

pdwActualOut *» &dwWiiteBytes 



50 



} 



); 



Note that above is just an example code that uses an HAL 
IOCTL to turn on the video. It is possible that the code to 
turn on video is trivial (or is available as function) in which 
case that code can be used directly. No matter how this is 
done, care must be taken to ensure that HAL_fVideoState 
correctly reflects the true state of the video (ON=l or 
OFF=0). 

1.1.14 HAL Keyboard Considerations 

1. When the HAL detects a key, it also needs to check 
HAL_fVideoState and if it is not set (i.e., video is currently 
not on) then it needs to turn on the video using the HAL 
IOCTL call (same code as in touch driver) and eats the key. 

2. An additional change is required to implement the 
delayed power off feature. On every power off key press, do 
the following 
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if (HAL_SystemBusy && 

(KeyPrcssed — KEY_POWER_OFF)) { 
Turn video off and ignore the key 
//sec 0 for the sample code and 
//comment about HAL_fVideoState 

} 



1.1.15 OOM system Considerations 

The OOM (out of memory message) code needs to check 
HAL_fVideoState and if it is not set (i.e., video is currently 
not on) then it needs to turn on the video using the HAL 
IOCTL call. It also needs to clear the HAL__SystemBusy 
flag. 

Sample Code 



HRADIO_FLAG CmdBuf; 

CindBuf.wStructSize = sizeof(HRADKD_FLAG); 

CmdBuf. wOperationCode - HRADIO_CMD_FLAG„SET, 

CmdBuf. wFlag - HRADIO_FLAG_VTDEO_STATE; 

OemIOControl( 

IOCTL_HAU_RADIO_CNTRL, // DWORD dwCode 
&CmdBuf, // PBYTE pBufln 

sizeof(CmdBuf), // DWORD dwUnln 

NULL, // PBYTE pBufOut 

0, // DWORD dwLenOut 

&dwWriteBytes // PDWORD pdwActualOut 

); 

CmdBuf. wFlag - HRADIO_FLAG_SYSTEM„BUSY; 

DWORD dwValue; 

while (1) { 

// get the value of SystemBusy counter 
CmdBuf.wOpeiationCode « HRADIO_CMD_GET, 
if (OemlOControl ( 

IOCTL_HAL _RADIO_CNTRL, // DWORD dwCode 
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&CmdBuf, // PBYTE pBufln 

sizeoffCmdBuf), // DWORD dwLenln 

&dwValue // PBYIE pBufOut 

sizeof(dwValue), // DWORD dwLenOut 

&dwWriteBytes // PDWORD pdwActualOut 



10 



20 



} 



){ 



if (dwValue 0) { 

break; // we are done 

} 

// decrement SystemBusy counter 
CmdBuf.dwOperationCode = HRADI 0_CM D_CLEAR; 
if (!OemIOControl( 

IOCTL_HAL_RADIO_CNTRL, // DWORD dwCode 



){ 
} 



ACrndBuf, 
sizeof (CmdBuf), 
NULL, 

&dwWriteBytes 
break; 



// PBYTE pBufln 

// DWORD dwLenln 
// PBYTE pBufOut 

// DWORD dwLenOut 

// PDWORD pdwActualOut 



1.1.16 OEM__Idle( ) Considerations 

OEM_Idle( ) is called by the Windows CE® kernel when 
there are no more threads or tasks to execute. This function 
is expected to do a timeout (typically 1-5 minutes) and if no 
system activity is detected, the system is shutdown. 

To implement the immediate shutdown feature, this func- 
tion should check HAL_fvideoState flag. If it is clear (Vide( 
) is off) then it does not need to do the idle timeout and 
should shutdown the system immediately. 

1.1.17 Sample Code 

1.1.17.1 HAL IOCTL Implementation 



BOOL OEMIoControl(DWORD dwlo Contra (Code, LPVOID lpInBuf, 
DWORD nlnBufSize, 

LPVOID lpOutBuf, DWORD nOutBufSize, LPDWORD 
lpBytesReturned) { 

BOOLretval - FALSE; 
DWORD leu; 

DWORD PhysAddr, value; 

PHRADIO_LOCK pHalLock; 
LPHRADIO_REGISTER pHalReg; 
LPHRADIO_FLAG pHalFlag; 
switch (dwIoControlCode) { 

case IOCTUJIAL_RADIO_CNTRL: 
if (nlnBufSize < sizeof(WORD)) { 

ScLLastError(ERROR_INVAUD_PARAMETER); 
break; 

} 

switch C(LPWORD)lpInBuf) { 

case HRADIO_CMD_LOCKPAGE: 
if (nlnBufSize < 

sizeof(HRADIO_LOCK)) { 

SetLastError(ERROR_JNSUFFICIENT_BUFFER); 

break; 

} 

pHalLock - (LPHRADIO_LOCK)lpInBuf; 
if (LockPages((LPVOID)pHalLock- 

>dwMemPtr, 1, APhysAddr, 2)) { 

memcpy (lpOutBuf, &PhysAddr, 

sizeof(DWORD)); 

retval - TRUE; 

} 

break; 

case HRADIO_CMD_REGISTER: 
if (nlnBufSize < 

sizeof(HRADIO__REGISTER)) { 
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SctLastErroi(ERROR_INSUFFICIEKT_BUFFER); 

break; 

} 

pHalReg = 

(LPHRADlO„REGISTER)lpInBuf; 

if(pHalReg->Device )= 1 && 

pHa!Reg->Devicc !«- 2) { 

SetUstError(ERROR_BAD_DEVICE); 
break; 

} 

if(pHatReg->Device « 1) { 

REG32(OEM_BASE+RADI01) = 

UnMapPtr(pHalReg->dwMemPtr); 

} else { 

REG32(OEM_BASE+RAD[02) - 

UnMapPtr(pHalReg->dwMemPtr); 

} 

if(!pHalReg->dwMemPtr) { 
retval » TRUE; 
break; 

if(aOutBufSize < sizeof(DWORD» { 
SetLastError(ERROR_INSUFFICIENT_BUFFER); 

break; 

} 

PhysAddr - pHalReg->Device — 1 ? 
(OEM_BASE+ RADIO 1) : (OEM_BASE+RADI02); 

memcpy(lpOutBuf, &PhysAddi, 

sizeoffDWORD)); 

retval - TRUE; 
bicak; 

case HRADIO_CMD_FLAG_SET: 
if(nInBufSize < 

sizco f (HRADIO_FLAG)) { 

SetLa 5 tError(ERROR_INSUFFICIEOT_BUFFER); 

break; 

} 

pHalFIag - (LPrIRADIO_FLAG)lp InBuf; 
switch (pHalFlag->wF1ag) { 

case HRADIO_FLAG_VIDEO_STATE: 
VideoOffO; 
break; 

case HRADIO„FLAG_SYSTEM _BUSY: 
// need to increment 

because multiple devices 
++REG32(OEM_BASE+RADIO_£USY); 

break; 

} 

retval = TRUE; 
break; 

case HRADIO_CMD_FLAG_CLEAR: 
if (nlnBufSize < 

sizeof(HRADIO_FLAG)) { 

SetLast£rror(ERROR_[NSUFFICIENrr_BUFFER); 

break; 

} 

pHalFIag - (LPHRADIO_FLAG)lp InBuf; 
switch (pHalFlag->wFlag) { 

case HRADIO _J 7 LAG_VIDEO_STATE: 
VideoOnO; 
break; 

case HRADIO_FLAG_SYSTEM__BUSY: 
// need to increment 

because multiple devices 

if 

(REG32(OEM__BASE+RADlO_BUSY)) { 
REG32(OEM_BASE+RADIO_BUSY); 

} 

break; 

} 

retval - TRUE; 
break; 

case HRADIO_CMD_FLAG_GET: 
if (nlnBufSize < 

sizeo f (HR ADIO_FLAG)) { 

SetLastE rror(ERROR_I NSU FFICIENT_B UFFER) ; 

break; 

} 
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if (nOulBufSizc < 5izcof(DWORD)) { 
SctLastError(ERROR_INSUFFICIENT_BUFFER)i 

break; 

} 

pHalFlag - (LPHRADIO_FLAG)lp InBuf ; 
value " 0; 

switch (pHalFlag->wRag) { 

case HRADIO_FLAG_VIDEO_STATE: 
value - 

(DWORD)REG8(OEM_BASE+VIDEO_OFF); 

break; 

case HRADIO_FLAG_SYSTEM_BUSY: 
value " 

REG32(OEM_BASE+RADIO_BUSY); 

break; 

} 

memcpy(lpOutBuf 7 &value, 

sizeoffDWORD)); 

retval - TRUE; 
break; 

} 

break; 

default: 

SetUstError(ERROR_NOT_SUPPORTED); 
break; 

} 

return retval; 

} 



1.1.17.2 HAL PowerOn Implementation 
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1.1.17.5 HAL Considerations for Touch Screen 
Same logic as keyboard changes described above. 
1.1.17.6 HAL Considerations for OEM_Idle( ) 



OEMPoweiOn( ) 

if (WakeupSource( )=CompactFlasn_RQ { 

ret = HRAD[0_CONTINUE„VIDnO_ON; 
if (RadioWakeupFunction != NULL) { 

ret = RadioWakeupFunction(HalControlBlock); 

} 

if (ret == HRADIO_CX)lSrnNUE_VrDEO__ON) { 

VideoInitfFALSE); 
}else 

if (ret == HRADIO_CONTINUE_VIDEO_OFF) { 

VidoelnitfTRUE); 
}else 

GotToSleepf ); 



1.1.17.3 HAL Changes for LCD 



VtdeoInit(BOOL KeepVftieoOff); 
VideoOn( ); 
VideoOff( ); 



1.1.17.4 HAL Considerations for Keyboard 



/* system already running *./ 

if ((DWORD)REG8(OEM_BASE+VIDEO_OFF)) { 
if (IsWakeupKey(kcy)) { 
Vldco(on); 

} 

IgnoreKeyf ); 

} 

if (TsPowerDownKcy(key)) { 

if (REG32(OEM_BASE+RADIO_BUSY)) { 

VideoOff( ); 

tgnoreKey( ); 
} else FrocessKeyC ); 

} 
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if VideoOff ( ) 

GoTbSleep( );- 
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Although the present invention has been described with 
reference to preferred embodiments, workers skilled in the 
art will recognize that changes may be made in form and 
detail without departing from the spirit and scope of the 
invention. 

What is claimed is: 

LA computer implemented method for receiving wireless 
information on a portable computing device, the method 
comprising: 

powering a wireless receiver only from a battery of the 

portable computing device; 
receiving wireless information; 

storing the wireless information in memory of the wire- 
less receiver; 

awaking a processor of the portable computing device 
when the wireless information fills a threshold of the 
memory available in the wireless receiver; and 

transferring the wireless information from the memory of 
the wireless receiver to memory of the portable com- 
puting device. 

2. The method of claim 1 and further comprising analyz- 
ing the wireless information received from the wireless 
receiver with the processor of the portable computing 
device. 

3. The method of claim 2 and further comprising power- 
ing another component of the portable computing device as 
a function of the wireless information received. 

4. The method of claim 3 wherein said another component 
comprises a display. 

5. The method of claim 4 and further comprising power- 
ing a keyboard of the portable computing device as a 
function of the wireless information received. 
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6. The method of claim 4 wherein the step of analyzing 
comprises analyzing a content of the wireless information. 

7. The method of claim 6 wherein the step of analyzing 
comprises analyzing a wireless address associated with the 
wireless information. 5 

8. The method of claim 7 wherein the wireless address 
includes a priority status entry indicating if priority mes- 
sages are received thereon, and wherein the method further 
includes analyzing the priority status entry associated with 
the wireless information. 

9. The method of claim 8 and further comprising power- 
ing another component of the portable computing device as 
a function of analyzing the priority status entry. 

10. The method of claim 9 wherein said another compo- 
nent comprises a display. 

11. The method of claim 10 and further comprising 15 
powering a keyboard of the portable computing device as a 
function of analyzing the priority status entry. 

12. The method of claim 8 and further comprising selec- 
tively changing the priority status entry of the wireless 
address. 20 

13. The method of claim 6 wherein the step of analyzing 
comprises analyzing a selected portion of the wireless 
information. 

14. The method of claim 13 wherein the portable com- 
puting device includes an executable application, and 2 s 
wherein the step of analyzing comprises analyzing the 
wireless information as a function of information from the 
executable application. 

15. The method of claim 1 wherein wireless inform ation 

is received in accordance with a wireless address, and ^ 
wherein the wireless address includes an operational status 
entry indicating if wireless information received thereon 
should be processed, and wherein storing the wireless infor- 
mation includes storing the wireless information in memory 
as a function of the operational status entry. 

16. The method of claim 15 and further comprising 35 
selectively changing the operational status entry of the 
wireless address. 

17. A wireless receiver for use in a portable computing 
device, the wireless receiver comprising: 

a radio receiver for receiving wireless information; 40 
memory for storing the wireless information and a list of 
wireless addresses for the portable computing device, 
wherein each address corresponds to selected informa- 
tion to be received, and wherein each address includes 
an associated operational status entry indicating 45 
enablement of the address; and 
a processor for processing wireless information as a 
function of the status entry of the address the wireless 
information is received on. 

18. The wireless receiver of claim 17 wherein the radio 50 
receiver, the memory and the processor are powered only 
from the portable computing device. 

19. The wireless receiver of claim 17 wherein each 
address in the list of wireless addresses for the portable 
computing device includes a priority status entry indicating 55 
if priority messages are received thereon. 

20. The wireless receiver of claim 17 wherein the memory 
stores a list of wireless addresses for the portable computing 
device, wherein each address corresponds to selected infor- 
mation to be received, and wherein each address includes a 60 
priority status entry indicating if priority messages are 
received thereon. 

21. A computer implemented method for receiving wire- 
less information on a portable computing device, wherein 
the wireless information is transmitted to the portable com- 65 
puling device with respect to wireless addresses, the method 
comprising: 
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providing a list of wireless addresses on the portable 
computing device, wherein each address corresponds to 
selected information to be received, and wherein each 
address includes an associated status entry indicating 
enablement of the address; and 

selectively enabling and disabling the status entry for the 
wireless address to allow receipt of the corresponding 
information as a function of an operating parameter of 
the portable computing device. 

22. The method of claim 21 wherein the step of selectively 
enabling and disabling includes enabling the status entry 
when the portable computing device is powered from a 
source other than a battery. 

23. The method of claim 21 wherein the portable com- 
puting device comprises a mobile device. 

24. The method of claim 21 wherein the portable com- 
puting device includes a wireless receiver, and the method 
further comprises: 

powering the wireless receiver only from the portable 

computing device; 
receiving wireless information on a wireless address; and 
storing the wireless information in memory of the wire- 
less receiver if status entry of the wireless address is 
enabled. 

25. The method of claim 21 wherein the operating param- 
eter is user adjustable. 

26. A computer implemented method for receiving wire- 
less information on a portable computing device, the method 
comprising: 

receiving wireless information from a wireless receiver; 

storing data information in memory indicative of the 
wireless information; and 

awaking a processor of the portable computing device 
reading the data information in memory indicative of 
the wireless information and powering other compo- 
nents of the portable computing device as a function of 
the data information, wherein the step of awaking 
includes the processor executing a body of code to 
receive a value indicative of the data information, and 
wherein the value indicative of the data information 
includes a first value indicating no further processing is 
needed for the wireless information. 

27. The method of claim 26 wherein the value indicative 
of the data information includes a second value indicating 
further processing is needed for the wireless information 
without another component. 

28. The method of claim 26 wherein the value indicative 
of the data information includes a third value indicating 
further processing is needed for the wireless information 
with another component. 

29. The method of claim 26 wherein the value indicative 
of the data information includes a second value indicating 
further processing is needed for the wireless information 
without at least one of a keyboard and a display. 

30. The method of claim 26 wherein the value indicative 
of the data information includes a third value indicating 
further processing is needed for the wireless information 
with at least one of a keyboard and a display. 

31. A wireless receiver for use in a portable computing 
device, the wireless receiver comprising: 

a radio receiver for receiving wireless information; 

memory for storing the wireless information and a list of 
wireless addresses for the portable computing device, 
wherein each address corresponds to selected informa- 
tion to be received, and wherein each address includes 
an associated operational status entry indicating 
enablement of the address; 
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a processor for processing the wireless information as a 
function of the operational status entry; and 

wherein the radio receiver, the memory and the processor 
are powered only from portable computing device. 

32. The wireless receiver of claim 31 wherein each 
address in the list of wireless addresses for the portable 
computing device includes a priority status entry indicating 
if priority messages are received thereon. 

33. A portable computing device for receiving wireless 
information, wherein the wireless information is transmitted 
to the portable computing device with respect to wireless 
addresses, portable computing device comprising: 

memory for storing a list of wireless addresses, wherein 
each address corresponds to selected information to be 
received, and wherein each address includes an asso- 
ciated status entry indicating enablement of the 
address; and 

a processor selectively enabling and disabling the status 
entry for the wireless address to allow receipt of the 
corresponding information as a function of an operating 
parameter of the portable computing device. 

34. The portable computing device of claim 33 wherein 
the processor receives user commands to selectively enable 
and disable a status entry. 

35. The portable computing device of claim 33 wherein 
each address includes a priority status entry indicating if 
priority messages are received thereon. 

36. A computer implement method for receiving wireless 
information on a portable computing device, wherein the 
wireless information is transmitted to the portable comput- 
ing device with respect to wireless addresses, the method 
comprising: 

providing a list of wireless addresses on the portable 
computing device, wherein each address corresponds to 
selected information to be received, and wherein each 
address includes an associated status entry indicating 
enablement of the address; and selectively enabling and 
disabling the status entry for the wireless address to 
allow receipt of the corresponding information as a 
function of an operating parameter of the portable 
computing device. 

37. The method of claim 36 wherein the step of selectively 
enabling and disabling includes enabling the status entry 
when the portable computing device is powered from a 
source other than a battery. 

38. The method of claim 36 wherein the portable com- 
puting device comprises a mobile device. 

39. The method of claim 36 wherein the portable com- 
puting device includes a wireless receiver, and the method 
further comprises: 

powering the wireless receiver only from the portable 

computing device; 
receiving wireless information on a wireless address; and 
storing the wireless information in memory of the wire- 
less receiver if status entry of the wireless address is 
enabled. 

40. The method of claim 36 wherein the operating param- 
eter is user adjustable. 

41. A computer implemened method for receiving wire- 
less information on a portable computing device, the method 
comprising: 

receiving wireless information from a wireless receiver; 
storing data information in memory indicative of the 

wireless information; and 
awaking a processor of the portable computing device 

reading the data information in memory indicative of 
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the wireless information and powering other compo- 
nents of the portable computing device as a function of 
the data information, wherein the step of awaking 
includes the processor executing a body of code to 
s receive a value indicative of the data information, and 
wherein the value indicative of the data information 
includes a first value indicating no further processing is 
needed for the wireless information. 

42. The method of claim 41 wherein the value indicative 
10 of the data information includes a second value indicating 

further processing is needed for the wireless information 
without another component. 

43. The method of claim 41 wherein the value indicative 
of the data information includes a third value indicating 

is further processing is needed for the wireless information 
with another component. 

44. The method of claim 41 wherein the value indicative 
of the data information includes a second value indicating 
further processing is needed for the wireless information 

20 with at least one of a keyboard and a display. 

45. The method of claim 41 wherein the value indicative 
of the data information includes a third value indicating 
further processing is needed for the wireless information 
with at least one a keyboard and a display. 

25 46. A wireless receiver for use in a portable computing 
device, the wireless receiver comprising: 

a radio receiver for receiving wireless information; 
memory for storing the wireless information and a list of 
wireless addresses for the portable computing device, 
30 wherein each address corresponds to selected informa- 
tion to be received, and wherein each address includes 
an associated operational status entry indicating 
enablement of the address; 
35 a processor for processing the wireless information as a 
function of the operational status entry; and 
wherein the radio receiver, the memory and the processor 
are powered only from the portable computing device. 

47. The wireless receiver of claim 46 wherein each 
40 address in the list of wireless addresses for the portable 

computing device includes a priority status entry indicating 
if priority messages are received thereon. 

48. A portable computing device for receiving wireless 
information, wherein the wireless information is transmitted 

4S to the portable computing device with respect to wireless 
addresses, the portable computing device comprising: 
memory for storing a list of wireless addresses, wherein 
each address corresponds to selected information to be 
received, and wherein each address corresponds to 
50 selected information to be received, and wherein each 
address includes an associated status entry indicating 
enablement of the address; and 
a processor selectively enabling and disabling the status 
entry for the wireless address to allow receipt of the 
55 corresponding information as a function of an operating 
parameter of the portable computing device. 

49. The portable computing device of claim 48 wherein 
the processor receives user commands to selectively enable 
and disable a status entry. 

60 50. The portable computing device of claim 48 wherein 
each address includes a priority status entry indicating if 
priority messages are received thereon. 

51. The portable computing device of claim 48 wherein 
the wireless information comprises information packets, 

65 each information packet comprising a first portion having 
topic information indicative of content in a second portion of 
the information packet, and wherein the memory stores 
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content filter data to ascertain if the information packet is to 
be discarded; and wherein the portable computing device 
further comprises a second processor for processing the 
second portion if the information packet is not discarded. 

52. Tlie portable computing device of claim 51 wherein 
the first-mentioned processor compares the first portion of 
the information packet to the content filter data as a function 
of the wireless address. 

53. The portable computing device of claim 52 wherein 
the content filter data comprises a plurality of data tables, 
each data table being associated with a wireless address. 

54. The portable computing device of claim 53 wherein 
each data table includes representations of at least one of a 
single, set or range of user preferences. 

55. The portable computing device of claim 54 wherein 
each data table comprises a bit-array, wherein a status of 
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each bit indicates a user preference for a selected type of 
information, and wherein the first-mentioned processor 
operates a hashing function upon the first portion to generate 
an offset value, and checks the status of the bit in the 
bit- array as a function of the offset value. 

56. The portable computing device of claim 53 wherein 
each data table comprises information stored pursuant to a 
hashing function. 

57. The portable computing device of claim 53 wherein 
the content filter data includes additional information stored 
as a function of the wireless address, 

58. The portable computing device of claim 57 wherein 
the first-mentioned processor filters the second portion as a 
function of the additional information. 
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